[PATCH wayland] protocol: remove implicit attach semantics

[Kristian Høgsberg]

On Thu, Mar 07, 2013 at 01:10:01PM +0200, Pekka Paalanen wrote:
> To match the Weston commit e7144fd175d1d68b91aa0cec7ab63381b79385a9:
> Author: Kristian Høgsberg <krh at bitplanet.net>
> Date:   Mon Mar 4 12:11:41 2013 -0500
> 
>     compositor: Only send release event in response to wl_surface.attach
> 
> Remove the implicit attach semantics from wl_surface.commit and .attach.
> 
> Before, if you did this on a wl_surface: attach, commit, commit, you
> would receive wl_buffer.release for both commits. After this change, you
> will only receive wl_buffer.release for the first commit. To get a
> second release, the same buffer must be attached again.
> 
> There is no need for the implicit attach on the second commit. If the
> compositor needs the wl_buffer for repainting, it will not release it to
> begin with. If the compositor does not need to keep the wl_buffer around
> for repainting, it will not need it for a new commit either.

Thanks Pekka, that wraps up this change.  I'll pull this and the
weston change back to the 1.0 branches and include in the 1.0.6
release.  This way we'll have consistent behavior across both
branches.

Kristian

> Signed-off-by: Pekka Paalanen <ppaalanen at gmail.com>
> ---
>  protocol/wayland.xml | 19 ++++++++-----------
>  1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 0ce68ef..9d276f8 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -755,10 +755,10 @@
>  
>  	The initial surface contents are void; there is no content.
>  	wl_surface.attach assigns the given wl_buffer as the pending wl_buffer.
> -	wl_surface.commit applies the pending wl_buffer as the new
> +	wl_surface.commit makes the pending wl_buffer the new
>  	surface contents, and the size of the surface becomes the size of
> -	the wl_buffer. The wl_buffer is also kept as pending, until
> -	changed by wl_surface.attach or the wl_buffer is destroyed.
> +	the wl_buffer. After commit, there is no pending buffer until the
> +	next attach.
>  
>  	Committing a pending wl_buffer allows the compositor to read the
>  	pixels in the wl_buffer. The compositor may access the pixels at any
> @@ -770,8 +770,6 @@
>  	event, and is not used by the compositor.
>  
>  	Destroying the wl_buffer after wl_buffer.release does not change the
> -	surface contents, even if the wl_buffer is still pending for the
> -	next commit. In such case, the next commit does not change the
>  	surface contents. However, if the client destroys the wl_buffer
>  	before receiving wl_buffer.release, the surface contents become
>  	undefined immediately.
> @@ -788,11 +786,10 @@
>      <request name="damage">
>        <description summary="mark part of the surface damaged">
>  	This request is used to describe the regions where the pending
> -	buffer (or if pending buffer is none, the current buffer as updated
> -	in-place) on the next wl_surface.commit will be different from the
> -	current buffer, and needs to be repainted. The pending buffer can be
> -	set by wl_surface.attach. The compositor ignores the parts of the
> -	damage that fall outside of the surface.
> +	buffer is different from the current surface contents, and where
> +	the surface therefore needs to be repainted. The pending buffer must
> +	be set by wl_surface.attach before sending damage. The compositor
> +	ignores the parts of the damage that fall outside of the surface.
>  
>  	Damage is double-buffered state, see wl_surface.commit.
>  
> @@ -894,7 +891,7 @@
>  	On commit, a pending wl_buffer is applied first, all other state
>  	second. This means that all coordinates in double-buffered state are
>  	relative to the new wl_buffer coming into use, except for
> -	wl_surface.attach itself. If the pending wl_buffer is none, the
> +	wl_surface.attach itself. If there is no pending wl_buffer, the
>  	coordinates are relative to the current surface contents.
>  
>  	All requests that need a commit to become effective are documented
> -- 
> 1.7.12.4
>