Bug 72854

Comment on attachment 90956 [details]
Subsurfaces Flicker

This obviously is not text/plain, so I'm changing the mime type. I hope this does not screw up the file, as it looks like it will be overwriting the file contents with the gibberish I see in a textarea edit box.

Oh good, the video file didn't break, and it shows the issue very nicely.

This seems to be about something in Mesa EGL breaking. The sw-rendered sub-surface is ok, but the GLESv2 widget is flickering to garbage and stuff. IOW, this is a buffer contents or buffer synchronization issue, and not breakage in the generic sub-surface code.

Neil?

Comment on attachment 90956 [details]
Subsurfaces Flicker

how about video/webm, now I can view it in the browser instead of downloading it ;)

Perhaps there is some relation to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=68296

...when I resize the attached program on that bug, I see flickering and buffer corruption with it.

I can replicate this problem if I use the Cairo image backend. It goes away if I apply this patch:

http://lists.freedesktop.org/archives/wayland-devel/2013-December/012650.html

That makes sense because without that patch there are two things attaching buffers to the triangle surface. Perhaps when the demo is normally running the buffer with the triangle normally ends up being attached last so it looks ok. However when the surface is being resized maybe it will sometimes cause Weston to repaint in-between attaching the secret cairo buffer and the triangle buffer so it renders garbage.

FWIW, I see the same type of flickering in the sample code (attachment 84295 [details]) that accompanies bug 68296.  Are they the same issue?

(In reply to comment #6)
> FWIW, I see the same type of flickering in the sample code (attachment 84295 [details]
> [details]) that accompanies bug 68296.  Are they the same issue?

Doh!  I already mentioned this in comment 4 :p

commit e4fdcf3e79acd688bd47f5e7a96217f324e31988
Author: Neil Roberts <neil@linux.intel.com>
Date:   Thu Dec 19 16:17:12 2013 +0000

    westoy: Add an option to explicitly disable cairo on a widget
    
    The subsurfaces example creates a subsurface widget and uses EGL to
    render to it directly rather than using the cairo context from the
    widget. In theory this shouldn't cause any problems because the westoy
    window code lazily creates the cairo surface when an application
    creates a cairo context. However commit fdca95c7 changed the behaviour
    to force the lazy creation at the beginning of each surface redraw.
    This ends up making the triangle surface get two attaches – one from
    Cairo and one from the direct EGL.
    
    It looks like it would be difficult to reinstate the lazy surface
    creation behaviour whilst still maintaining the error handling for
    surface creation because none of the redraw handlers in the example
    clients are designed to cope with that. Instead, this patch adds an
    explicit option on a widget to disable creating the Cairo surface and
    the subsurface example now uses that.