On Fri, 20 Nov 2015 15:49:58 -0600 Derek Foreman <der...@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 <der...@osg.samsung.com> > --- > > New change: Explain that damages can't be combined until commit > > Also, copy the new wl_surface.damage text that doesn't require attach > to be before damage > > (enough text is new that I haven't carried over any RBs) > > protocol/wayland.xml | 48 ++++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 46 insertions(+), 2 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 525e092..4d75f39 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,46 @@ > </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 the late stages of wl_surface.commit, > + damage from wl_surface.damage and wl_surace.damage_buffer must > + be accumulated separately and only combined during > + wl_surface.commit. Hi, yeah, this is pretty good now. The last paragraph is aimed at compositor writers, so it should mention compositor or server. "Late stages" is also a bit vague, I think we could be more explcit there. How about: 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 the earliest. I'm also reserving the right to not combine the damages at commit but later, which might perhaps be useful once the buffer queueing extension is revived. > + </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"> But that's just minor adjustment of the wording. The definition looks good. Thanks, pq
pgpif_SoUVmXy.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel