<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - weston-subsurfaces does not render/display" href="https://bugs.freedesktop.org/show_bug.cgi?id=72612#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - weston-subsurfaces does not render/display" href="https://bugs.freedesktop.org/show_bug.cgi?id=72612">bug 72612</a> from <a class="email" href="mailto:neil@linux.intel.com" title="Neil Roberts <neil@linux.intel.com>"> Neil Roberts</a> <pre>> There should not be a secret cairo EGL surface for the triangle widget. If > there is, I think that should be fixed first. I guess it just hasn't been an > issue until now. I posted a patch to the mailing list to fix this: <a href="http://lists.freedesktop.org/archives/wayland-devel/2013-December/012650.html">http://lists.freedesktop.org/archives/wayland-devel/2013-December/012650.html</a> However it turns out I was wrong and that doesn't fix the problem. The problem still happens even if you pass -n to disable the triangle surface. The sequence of drawing without the triangle surface goes like this: 1. draw main surface 2. draw subsurface 3. swap subsurface 4. swap main surface As mentioned in <a href="show_bug.cgi?id=72612#c1">comment #1</a>, the first thing Cairo does when flushing (AKA swapping) the surface is to ‘acquire’ the GL context. After acquiring the context it will bind the context again with the EGL surface for the Cairo surface that is to be swapped. Acquiring the context binds whatever surface Cairo used last. At step 4 the last surface that was bound is the subsurface. That has a frame callback installed following the swap in step 3 which means that when eglMakeCurrent is called it will block in get_back_bo. This will block until the main surface is swapped which will never happen so it blocks forever. > I think I have assumed, that eglSwapInterval(0) would cause the EGL > implementation to never stall indefinitely, but is that a feasible > assumption? Yes, that is correct. With eglSwapInterval(0) Mesa should only ever block on a sync request and there should be no reason why that wouldn't come instantly. This problem isn't really related to the eglSwapInterval(0) changes but instead it is triggered by blocking on the frame callback in get_back_bo instead of in eglSwapBuffers. That was a separate change independent of eglSwapInterval to fix the 3 buffers problem. > Btw. how about --with-cairo=image? I haven't tested it but I assume using the image backend would fix the problem because that doesn't have the mess with rebinding the EGL context. I think the best fix would be to make Mesa not call get_back_bo from eglMakeCurrent. The patch that added this call is this one: <a href="http://cgit.freedesktop.org/mesa/mesa/commit/?h=db9c151d">http://cgit.freedesktop.org/mesa/mesa/commit/?h=db9c151d</a> I tried recklessly removing the call to intel_prepare_render to see if the situation has changed since 2010 but it breaks quite catastrophically. It looks like making this change would be a fair bit of work.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>