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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
