[RFC v.2] Extend wl_surface protocol

[Daniel Stone]

Hi,

On 11 November 2013 15:52, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Fri, 08 Nov 2013 23:49:25 +0100
> Axel Davy <davy at clipper.ens.fr> 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