Core protocol change; [RFC v2] Wayland presentation extension

[Axel Davy]

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.

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

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.

Axel Davy