Pekka Paalanen wrote:
If the server somehow knew that B2 was not in response to the resize, it
could composite the old buffers for the main surface with B2 and then
free B1. The client for the subsurface could then wait for B1 to be
freed before it starts working on the new resize surface.
I think this could be known by adding some kind of serial numbers in the
set-sync and buffer attach requests. It might be nice to fix this so if
the resize is slow to respond the video playback keeps happening.
That sounds complex. I'm not sure this is worth fixing.
Probably not, though the display would be more correct with this fix.
That already happens. If you commit new buffers to a normal surface
faster than the server is displaying them, only the newest buffer
will be kept by the server (Weston), and the previous not yet
presented buffer will be released. The triple-buffering logic is
implicitly built-in.
Yes but it sounds like the need for triple-buffering is not unique to
subsurfaces, a main surface can need it as well. That sounds more right
to me, I was bothered by the idea that subsurfaces somehow have
different requirements, though I came to the wrong conclusion that
somehow triple buffering was never needed.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
