<div dir="ltr"><div>I am pretty certain you can just convert wl_surface.damage coordinates *to* buffer coordinates, using the transform the old buffer was attached with, and thus merge all the wl_surface.damage and wl_surface.damage_buffer into a single region in buffer space.</div><div><br></div><div>If the transformation does not change, you can back-transform this region into the changed region in screen space.<br><br></div><div>You seem to be worried about what happens if the transformation is different between the old and new buffers. But in that case the on-screen changed area is the union of the entire old buffer with it's old transform and the new buffer with it's new transform. The damage region is ignored when figuring out the screen-space damage so it does not matter what it was set to.<br><br></div><div>If a client actually sends the "correct" wl_surface.damage for a transform change, it will be a region that translates to cover the entire old buffer. This may be excessive but is harmless.<br><br></div><div>I suppose rotating a perfectly square buffer which is filled with a solid color could, under the old system, turn into no damage, while the new one will not know (unless it compares the buffers) and damage an unchanged area. However this seems really trivial. Any client that actually tries to do this correctly with wl_surface.damage will send a region that necessarily translates to something that includes all the damage to the buffer.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 1:49 PM, Derek Foreman <span dir="ltr"><<a href="mailto:derekf@osg.samsung.com" target="_blank">derekf@osg.samsung.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">wl_surface.damage uses surface local co-ordinates.<br>
<br>
Buffer scale and buffer transforms came along, and EGL surfaces<br>
have no understanding of them.<br>
<br>
Theoretically, clients pass damage rectangles - in Y-inverted surface<br>
co-ordinates) to EGLSwapBuffersWithDamage, and the EGL implementation<br>
passed them on to wayland. However, for this to work the EGL<br>
implementation must be able to flip those rectangles into the space<br>
the compositor is expecting, but it's unable to do so because it<br>
doesn't know the height of the transformed buffer.<br>
<br>
So, currently, EGLSwapBuffersWithDamage is unusable and EGLSwapBuffers<br>
has to pass (0,0) - (INT32_MAX, INT32_MAX) damage to function.<br>
<br>
wl_surface.damage_buffer allows damage to be registered on a surface<br>
in buffer co-ordinates, avoiding this problem.<br>
<br>
Credit where it's due, these ideas are not entirely my own:<br>
Over a year ago the idea of changing damage co-ordinates to buffer<br>
co-ordinates was suggested (by Jason Ekstrand), and it was at least<br>
partially rejected and abandoned. At the time it was also suggested<br>
(by Pekka Paalanen) that adding a new wl_surface.damage_buffer request<br>
was another option.<br>
<br>
This will eventually resolve:<br>
<a href="https://bugs.freedesktop.org/show_bug.cgi?id=78190" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=78190</a><br>
by making the problem irrelevant.<br>
<br>
Signed-off-by: Derek Foreman <<a href="mailto:derekf@osg.samsung.com">derekf@osg.samsung.com</a>><br>
---<br>
<br>
</span>New change: Explain that damages can't be combined until commit<br>
<br>
Also, copy the new wl_surface.damage text that doesn't require attach<br>
to be before damage<br>
<br>
(enough text is new that I haven't carried over any RBs)<br>
<br>
protocol/wayland.xml | 48 ++++++++++++++++++++++++++++++++++++++++++++++--<br>
1 file changed, 46 insertions(+), 2 deletions(-)<br>
<br>
diff --git a/protocol/wayland.xml b/protocol/wayland.xml<br>
index 525e092..4d75f39 100644<br>
<span class="">--- a/protocol/wayland.xml<br>
+++ b/protocol/wayland.xml<br>
@@ -176,7 +176,7 @@<br>
</event><br>
</interface><br>
<br>
- <interface name="wl_compositor" version="3"><br>
+ <interface name="wl_compositor" version="4"><br>
<description summary="the compositor singleton"><br>
A compositor. This object is a singleton global. The<br>
compositor is in charge of combining the contents of multiple<br>
@@ -986,7 +986,7 @@<br>
</event><br>
</interface><br>
<br>
- <interface name="wl_surface" version="3"><br>
+ <interface name="wl_surface" version="4"><br>
<description summary="an onscreen surface"><br>
A surface is a rectangular area that is displayed on the screen.<br>
It has a location, size and pixel contents.<br>
</span>@@ -1109,6 +1109,10 @@<br>
<span class=""> wl_surface.commit assigns pending damage as the current damage,<br>
and clears pending damage. The server will clear the current<br>
damage as it repaints the surface.<br>
+<br>
+ Alternatively, damage can be posted with wl_surface.damage_buffer<br>
+ which uses buffer co-ordinates instead of surface co-ordinates,<br>
+ and is probably the preferred and intuitive way of doing this.<br>
</description><br>
<br>
<arg name="x" type="int"/><br>
</span>@@ -1325,6 +1329,46 @@<br>
<span class=""> </description><br>
<arg name="scale" type="int"/><br>
</request><br>
+<br>
+ <!-- Version 4 additions --><br>
+ <request name="damage_buffer" since="4"><br>
+ <description summary="mark part of the surface damaged using buffer co-ordinates"><br>
+ This request is used to describe the regions where the pending<br>
+ buffer is different from the current surface contents, and where<br>
</span>+ the surface therefore needs to be repainted. The compositor<br>
+ ignores the parts of the damage that fall outside of the surface.<br>
<span class="">+<br>
+ Damage is double-buffered state, see wl_surface.commit.<br>
+<br>
+ The damage rectangle is specified in buffer coordinates.<br>
+<br>
+ The initial value for pending damage is empty: no damage.<br>
</span>+ wl_surface.damage_buffer adds pending damage: the new pending<br>
+ damage is the union of old pending damage and the given rectangle.<br>
<span class="">+<br>
+ wl_surface.commit assigns pending damage as the current damage,<br>
+ and clears pending damage. The server will clear the current<br>
+ damage as it repaints the surface.<br>
+<br>
+ This request differs from wl_surface.damage in only one way - it<br>
+ takes damage in buffer co-ordinates instead of surface local<br>
+ co-ordinates. While this generally is more intuitive than surface<br>
</span>+ co-ordinates, it is especially desirable when using wp_viewport<br>
<span class="">+ or when a drawing library (like EGL) is unaware of buffer scale<br>
+ and buffer transform.<br>
+<br>
</span>+ Since it is impossible to convert between buffer and surface<br>
+ co-ordinates until the late stages of wl_surface.commit,<br>
+ damage from wl_surface.damage and wl_surace.damage_buffer must<br>
+ be accumulated separately and only combined during<br>
+ wl_surface.commit.<br>
<span class="im HOEnZb">+ </description><br>
+<br>
+ <arg name="x" type="int"/><br>
+ <arg name="y" type="int"/><br>
+ <arg name="width" type="int"/><br>
+ <arg name="height" type="int"/><br>
+ </request><br>
</interface><br>
<br>
</span><span class="im HOEnZb"> <interface name="wl_seat" version="5"><br>
--<br>
2.6.2<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div></div></div></div>