<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#c5">Comment # 5</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:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>The triangle code sets up its own frame callback to "independently" drive the animation. 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. The interactions and deadlock avoidance with EGL vs. synchronized sub-surfaces has always been delicate. First it was only the frame callback, but now you have the wl_buffer.releases as well. I believe it is a fact, that synchronized sub-surfaces will require one more buffer in the rotation than what a normal surface does, at least if they run "independently". The interactions are hard to follow, unfortunately. I think I have assumed, that eglSwapInterval(0) would cause the EGL implementation to never stall indefinitely, but is that a feasible assumption? Btw. how about --with-cairo=image? I am using --with-cairo=image, so that's another possible reason why I might never see the problem.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>