Core protocol change; [RFC v2] Wayland presentation extension

[Pekka Paalanen]

On Tue, 18 Feb 2014 18:34:24 +0100
Axel Davy <axel.davy at ens.fr> wrote:

> Hi,
> > If you read the above paragraph carefully, you see that the last
> > sentence CHANGES EXISTING WAYLAND CORE PROTOCOL BEHAVIOUR.
> >
> > The change is very subtle. It means, that without a wl_surface.attach,
> > the buffer state is no longer applied on commit at all! To recap, the
> > buffer state is:
> > - frame callbacks (!)
> > - set_buffer_transform
> > - set_buffer_scale
> > - the src_* arguments of wl_viewport.set
> >
> > The reason is explained in my recent email:
> > http://lists.freedesktop.org/archives/wayland-devel/2014-February/013293.html
> >
> > An immediate commit without an attach should not apply any buffer
> > state, because previous queueing of frames may have left buffer state
> > that is incorrect for the currently showing buffer. Immediate commits
> > without attach are used to update surface (and shell!) state, and
> > applying incorrect buffer state could cause a visual glitch.
> >
> > We could claim, that this change in the core protocol exists only if
> > the presentation extension is advertised by the server, but that would
> > cause a lot more work to fix clients that get bit by this change, rather
> > than fix the clients to always attach a wl_buffer when they want to
> > change buffer state, even if it is the same buffer they just attached
> > and committed already.
> >
> > Therefore I would like to bring the concepts of surface state and
> > buffer state to the core protocol, and have the core procotol define
> > that buffer state is applied only if there is an attach.
> >
> > In the past, we already changed the wl_surface.attach semantics to not
> > re-attach the "current" buffer again, when there is a wl_surface.commit.
> > The practical consequence of that was that a commit without an attach
> > cannot cause any wl_buffer on this surface to become reserved and
> > readable by the server, and hence no (new) wl.buffer.release would be
> > posted either.
> >
> > That means that clients already need to re-attach the same wl_buffer
> > again, if they changed the buffer contents and want to show the new
> > image. I think this should mitigate the impact of the core protocol
> > change.
> >
> > I guess the only interesting case is the frame callback, and whether
> > anyone (ab)uses it without an attach.
> >
> > Would this proposition be acceptable?
> >
> >
> > Thanks,
> > pq
> >
> 
> As Jason pointed, it's useful to be able to do frame+commit when we 
> want, outside of the part of the program doing attach+damage+commit, and 
> get the frame callback.
> I agree the definition of the frame callback should be clarified though.
> 
> I think a clarification of frame shouldn't break existing programs.

Yeah, not breaking existing programs is the rule. I hoped no-one would
have abused it yet.

> I don't see the point of queuing frame callbacks, and that should be 
> more apparent if we change frame meaning.

With EGL, if frame callbacks are queued and swap_interval = 1, the EGL
implementation will block the app on the next draw or swap until the
queued buffer is applied in the compositor. Is this useful or harmful?

The app is intentionally queueing with swap_interval = 1, so what
should it expect to happen?

> I've seen you proposed the change:
> 
> -	A client can request a frame callback even without an attach,
> -	damage, or any other state changes. wl_surface.commit triggers
> -	display update, so the callback event will arrive after the next
> -	output refresh where the surface is visible.
> -
> 
> Why not replace that by:
> 
> A client can request a frame callback even without an attach,
> damage, or any other state changes. The frequency at which the frame
> callbacks are called by the compositor is not defined,
> but the client can expect it to be similar to the refresh rate if the 
> surface is focused and visible on the screen.

I'll reply to this in the new thread I started with the patch "[PATCH
wayland] protocol: strike the note of frame callback triggering time",
where I proposed that.


Thanks,
pq