Created attachment 90956 [details] Subsurfaces Flicker Steps: 1. Launch Weston 2. Launch Weston terminal : weston-terminal 3. Execute Weston subsurfaces : Weston-subsurfaces 4. Resize the window using mouse by dragging the window corner in and out. Actual Result : Weston subsurfaces flicker when resizing the window. Please find the attached video. Expected result : Weston-subsurfaces window should render smoothly on resizing Environment : Kernel:3.9.5-301.fc19.x86_64 wayland (HEAD) 1.3.91-0-g01bde63 drm (HEAD) libdrm-2.4.50-0-g4c5de72 mesa (HEAD) remotes/origin/10.0-0-g6f7da01 libva (HEAD) libva-1.2.1-0-g88ed1eb intel-driver (HEAD) 1.2.1-0-g8f306e3 weston (HEAD) remotes/origin/master-0-gdf42a80 efl (HEAD) remotes/origin/efl-1.8-0-g90c2320 elementary (HEAD) remotes/origin/elementary-1.8-0-ge077db6 wayland-fits (HEAD) remotes/origin/HEAD-0-gcd75d94
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.