Mir

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

Bug #1281938 reported by Daniel van Vugt on 2014-02-19

This bug affects 1 person

	Status	Importance	Assigned to	Milestone
Mir	Fix Released	Medium	Daniel van Vugt	Mir 0.1.6
mesa (Ubuntu)	Invalid	Medium	Unassigned
mir (Ubuntu)	Fix Released	Medium	Unassigned

Bug Description

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.

See original description

Tags:

Related branches

lp://staging/~vanvugt/mir/fix-1281938

Merged into lp://staging/mir at revision 1417

PS Jenkins bot (community): Approve (continuous-integration) on 2014-02-21

Kevin DuBois (community): Approve on 2014-02-21

Alan Griffiths: Approve on 2014-02-20

lp://staging/ubuntu/trusty-proposed/mir

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2014-02-19:

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).

Changed in mir:
importance:	High → Medium

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2014-02-19:

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.

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2014-02-19:

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

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2014-02-19:

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

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2014-02-19:

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

Changed in mir:
status:	Triaged → Invalid
Changed in mesa (Ubuntu):
status:	New → Triaged
importance:	Undecided → Medium

Daniel van Vugt (vanvugt) on 2014-02-19

Changed in mir:
assignee:	nobody → Daniel van Vugt (vanvugt)

Daniel van Vugt (vanvugt) on 2014-02-19

Changed in mir:
status:	Invalid → In Progress
milestone:	none → 0.1.6
summary:	- Mir shows an old frame on client startup + Mir shows an old frame on client startup (for Mesa GL clients)

Daniel van Vugt (vanvugt) on 2014-02-19

description:

updated

Revision history for this message

PS Jenkins bot (ps-jenkins) wrote on 2014-02-21:

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

Changed in mir:
status:	In Progress → Fix Committed

Daniel van Vugt (vanvugt) on 2014-02-28

Changed in mir:
status:	Fix Committed → Fix Released

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2014-03-11:

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

Changed in mir (Ubuntu):
importance:	Undecided → Medium
status:	New → Fix Released

Daniel van Vugt (vanvugt) on 2016-02-10

tags:

added: egl-platform-mir

Revision history for this message

Timo Aaltonen (tjaalton) wrote on 2019-03-04:

Mir EGL platform is gone

Changed in mesa (Ubuntu):
status:	Triaged → Invalid

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.