Mir shows an old frame on client startup (for Mesa GL clients)

[Daniel van Vugt]

Mir shows an old frame on client startup.

Test case (1):
  1. Start and stop one client at a time:
     bin/mir_demo_client_egltriangle -s 500x500
     bin/mir_demo_client_eglflash -s 500x500
     ...
Expected: Each client only shows its own frames
Observed: The first frame of each client seems to be the last frame of the _previous_ client.

Test case(2) - more definitive but requires hacking:
  1. Insert a long sleep in your client code just before eglSwapBuffers
Expected: The Mir server never shows the client till after the sleep has finished.
Observed: The Mir server composites the client immediately on startup, with old/invalid pixel data. It only gets replaced with a valid frame after the sleep finishes.

[Daniel van Vugt (vanvugt)]

Tried bisecting, but the bug seems to have existed since last year at least. Or perhaps exists in Mesa.

I can't see any evidence of the bug occurring with software clients, only hardware (GL) clients. Also, I have traced through the compositor, renderer and SwitchingBundle. All of them are behaving correctly and only showing client buffers after the client submits them. However, I am suspicious of the GLES extensions we use for binding textures of hardware surfaces... that might be resulting in the wrong texture somehow (perhaps like bug 1270245).

[Daniel van Vugt (vanvugt)]

I'm suspicious of eglCreateImageKHR and glEGLImageTargetTexture2DOES having synchronization problems. It's as if we're getting the wrong EGLImage and/or not synchronized with the client properly.

[Daniel van Vugt (vanvugt)]

Found the problem. Mir EGL clients will trigger a next_buffer request to the server immediately on startup, before any rendering has occurred. To the SessionMediator this counts as the first _real_ frame, it marks the BasicSurface as posted and it gets composited immediately. Even though the client has not drawn anything yet.

The premature next_frame is coming from eglCreateWindowSurface, at a time in the client long before it has rendered anything:

(gdb) bt
#0 MirSurface::request_and_wait_for_next_buffer (this=0x611cb0)
    at /home/dan/bzr/mir/start/src/client/mir_surface.cpp:408
#1 0x00007ffff2b70d04 in mir::client::mesa::NativeSurface::advance_buffer (
    this=0x7fffec001ec0, buffer_package=0x7fffffffdb70)
    at /home/dan/bzr/mir/start/src/client/mesa/native_surface.cpp:58
#2 0x00007ffff2b70c24 in (anonymous namespace)::advance_buffer_static (
    surface=0x7fffec001ec0, buffer_package=0x7fffffffdb70)
    at /home/dan/bzr/mir/start/src/client/mesa/native_surface.cpp:31
#3 0x00007ffff77aa20b in ?? ()
   from /usr/lib/x86_64-linux-gnu/mesa-egl/libEGL.so.1
#4 0x00007ffff77aa6e9 in ?? ()
   from /usr/lib/x86_64-linux-gnu/mesa-egl/libEGL.so.1
#5 0x00007ffff779abc3 in eglCreateWindowSurface ()
   from /usr/lib/x86_64-linux-gnu/mesa-egl/libEGL.so.1
#6 0x0000000000402bd4 in mir_eglapp_init (argc=1, argv=0x7fffffffe6a8,
    width=0x7fffffffde9c, height=0x7fffffffdea0)
    at /home/dan/bzr/mir/start/examples/eglapp.c:379
#7 0x0000000000401d8a in main (argc=1, argv=0x7fffffffe6a8)
    at /home/dan/bzr/mir/start/examples/egltriangle.c:85

[Daniel van Vugt (vanvugt)]

Also affects Mesa. Looks like the problem is originating in the Mir support in Mesa.

[Daniel van Vugt (vanvugt)]

Apparently the winner is:
https://github.com/RAOF/mesa/blob/egl-platform-mir/src/egl/drivers/dri2/platform_mir.c#L201

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:mir/devel at revision None, scheduled for release in mir, milestone Unknown

[Daniel van Vugt (vanvugt)]

This bug was fixed in the package mir - 0.1.6+14.04.20140310-0ubuntu1
---------------
mir (0.1.6+14.04.20140310-0ubuntu1) trusty; urgency=medium

[Timo Aaltonen (tjaalton)]

Mir EGL platform is gone