Jason Ekstrand wrote:
Ok, you are in the crazy edge-case that I feared.
I'm not sure how crazy edge-case this is. A client wanting to limit the number of buffers to 2 seems really useful, not just for saving memory but for making it easier on the client implementation.
Therefore a client trying to do double buffering (or triple buffering, or any kind of fixed-number buffering) is going to be interested in getting the buffer-release event as soon as possible when it wants to draw.
The deferring makes sense because it assumes clients will not want to draw until an event or frame callback comes in, so they are not interested in the buffer release until then. But it looks like the current implementation will still defer any buffer-release that is not ready after this event until the next event! I think clients will want the buffer release as soon as possible in this case.
So could it queue the buffer-release if and only if no events have been delivered to the client since the buffer for the surface was changed? If an event has been sent then it sends the buffer release immediately.
This would also make the sync event work like you propose, as the client would only have to sync once. The echo of the sync would count as an event and cause the buffer release to be sent asap.
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
