Hi, On 11 November 2013 15:52, Pekka Paalanen <[email protected]> wrote: > On Fri, 08 Nov 2013 23:49:25 +0100 > Axel Davy <[email protected]> wrote: >> Except this problem, I think your protocol proposition is fine. >> I suggest to change the spec >> to include the fact that queue is a more complete commit, >> and will take into account a pending frame request, >> and associate it to the wl_buffer we queue. >> Since the frame request is linked to a callback, the client >> can find to which buffer it is associated when it gets the >> frame feedback. > > I don't think it makes sense to say, that "When the compositor > applies a buffer from the buffer queue, it will also implicitly commit > all pending frame requests." That's implicit behaviour across two > different interfaces in a rather surprising way, IMHO.
Hmm, I can see the need for that though. For smooth resizing with a queue whilst maintaining constant frame rates, it might be nice to have a method which latches the next commit to a particular frame time to, e.g., keep your input region consistent with your newly-resized buffer. Most of the alternatives I can think of involve clearing the queue, which is quite risky as if you have multiple frames queued for display and get a resize request ... what do you do? Either you can wait until the queue drains and only then resize - which makes you hugely latent in the case of large queues - or you do an attach and commit with new size to clear the queue, in which case you risk jumping either backwards or forwards in time, because you don't know which frame will be on screen when your attach/commit gets displayed. Same goes for crop/scale ... Cheers, Daniel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
