[RFC v.2] Extend wl_surface protocol

[Pekka Paalanen]

On Mon, 11 Nov 2013 21:36:43 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> 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.

So, should we add an event similar to the frame callback, into the
wl_presentation_time interface?

Otherwise the client has no way to know soon enough which buffer from
the queue caused it to trigger, does it?

Is there actually *any* way to avoid the race here? The moment a client
receives any event, the compositor may have advanced already. Is that
any better than the client reading the clock, and inferring from that
which frame should be on display at the time? (That should actually get
pretty accurate in a steady state, if the client is able to synchronize
to the scanout cycle.)

Hmm, or maybe there is, although this would be excessively heavy. When
you get a resize event, read the clock, and render a bunch of frames in
the new size into the near future. Then, clear the queue and submit the
frames in the order of highest timestamp first. The submitted
timestamps will catch up with the compositor's processing at some
point, and you don't jump forward/backward any more that you normally
do. (Doesn't pulseaudio use something like this to rewrite the audio
chunks in flight, except that works at a sample rather than frame
level?)

> Same goes for crop/scale ...

Crop & scale is the same kind of surface state as input/opaque regions
etc. Is that what you mean?

Is it about matching a crop & scale state change to a specific queued
buffer? To do that race-free, I think we would just need to queue all
surface state instead of just the buffers, no?


Thanks,
pq