[PATCH wayland v4] protocol: Add wl_surface.damage_buffer
Jason Ekstrand
jason at jlekstrand.net
Thu Nov 26 20:05:40 PST 2015
On Nov 26, 2015 1:44 PM, "Derek Foreman" <derekf at osg.samsung.com> wrote:
>
> wl_surface.damage uses surface local co-ordinates.
>
> Buffer scale and buffer transforms came along, and EGL surfaces
> have no understanding of them.
>
> Theoretically, clients pass damage rectangles - in Y-inverted surface
> co-ordinates) to EGLSwapBuffersWithDamage, and the EGL implementation
> passed them on to wayland. However, for this to work the EGL
> implementation must be able to flip those rectangles into the space
> the compositor is expecting, but it's unable to do so because it
> doesn't know the height of the transformed buffer.
>
> So, currently, EGLSwapBuffersWithDamage is unusable and EGLSwapBuffers
> has to pass (0,0) - (INT32_MAX, INT32_MAX) damage to function.
>
> wl_surface.damage_buffer allows damage to be registered on a surface
> in buffer co-ordinates, avoiding this problem.
>
> Credit where it's due, these ideas are not entirely my own:
> Over a year ago the idea of changing damage co-ordinates to buffer
> co-ordinates was suggested (by Jason Ekstrand), and it was at least
> partially rejected and abandoned. At the time it was also suggested
> (by Pekka Paalanen) that adding a new wl_surface.damage_buffer request
> was another option.
>
> This will eventually resolve:
> https://bugs.freedesktop.org/show_bug.cgi?id=78190
> by making the problem irrelevant.
>
> Signed-off-by: Derek Foreman <derekf at osg.samsung.com>
This looks fine by me
Reviewed-by: Jason Ekstrand <jason at jlekstrand.net>
> ---
>
> Changes from v3:
> replaced the last paragraph with Pekka's version
> (with one tiny grammar change)
>
> protocol/wayland.xml | 49
+++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index f9e6d76..4e97bb9 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -176,7 +176,7 @@
> </event>
> </interface>
>
> - <interface name="wl_compositor" version="3">
> + <interface name="wl_compositor" version="4">
> <description summary="the compositor singleton">
> A compositor. This object is a singleton global. The
> compositor is in charge of combining the contents of multiple
> @@ -986,7 +986,7 @@
> </event>
> </interface>
>
> - <interface name="wl_surface" version="3">
> + <interface name="wl_surface" version="4">
> <description summary="an onscreen surface">
> A surface is a rectangular area that is displayed on the screen.
> It has a location, size and pixel contents.
> @@ -1109,6 +1109,10 @@
> wl_surface.commit assigns pending damage as the current damage,
> and clears pending damage. The server will clear the current
> damage as it repaints the surface.
> +
> + Alternatively, damage can be posted with wl_surface.damage_buffer
> + which uses buffer co-ordinates instead of surface co-ordinates,
> + and is probably the preferred and intuitive way of doing this.
> </description>
>
> <arg name="x" type="int"/>
> @@ -1325,6 +1329,47 @@
> </description>
> <arg name="scale" type="int"/>
> </request>
> +
> + <!-- Version 4 additions -->
> + <request name="damage_buffer" since="4">
> + <description summary="mark part of the surface damaged using
buffer co-ordinates">
> + This request is used to describe the regions where the pending
> + buffer is different from the current surface contents, and where
> + the surface therefore needs to be repainted. The compositor
> + ignores the parts of the damage that fall outside of the surface.
> +
> + Damage is double-buffered state, see wl_surface.commit.
> +
> + The damage rectangle is specified in buffer coordinates.
> +
> + The initial value for pending damage is empty: no damage.
> + wl_surface.damage_buffer adds pending damage: the new pending
> + damage is the union of old pending damage and the given rectangle.
> +
> + wl_surface.commit assigns pending damage as the current damage,
> + and clears pending damage. The server will clear the current
> + damage as it repaints the surface.
> +
> + This request differs from wl_surface.damage in only one way - it
> + takes damage in buffer co-ordinates instead of surface local
> + co-ordinates. While this generally is more intuitive than surface
> + co-ordinates, it is especially desirable when using wp_viewport
> + or when a drawing library (like EGL) is unaware of buffer scale
> + and buffer transform.
> +
> + Since it is impossible to convert between buffer and surface
> + co-ordinates until all the possible parameters affecting the
> + surface size and the buffer-surface mapping are known at
> + wl_surface.commit time, damage from wl_surface.damage and
> + wl_surface.damage_buffer must be accumulated separately in a
> + compositor and combined during wl_surface.commit at the earliest.
This last paragraph seems a bit out-of-place to me but I don't have a
better suggestion at the moment.
> + </description>
> +
> + <arg name="x" type="int"/>
> + <arg name="y" type="int"/>
> + <arg name="width" type="int"/>
> + <arg name="height" type="int"/>
> + </request>
> </interface>
>
> <interface name="wl_seat" version="5">
> --
> 2.6.2
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151126/0fc8244f/attachment.html>
More information about the wayland-devel
mailing list