[PATCH 1/4 wayland] add damage2 api

[Pekka Paalanen]

On Thu,  7 Jun 2012 06:33:54 +0300
Zhao Halley <halley.zhao at intel.com> wrote:

> ---
>  protocol/wayland.xml |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 67ece1b..9f2de9f 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -631,6 +631,22 @@
>        <arg name="height" type="int"/>
>      </request>
>  
> +    <request name="damage2">
> +      <description summary="mark part of the surface damaged with resize supported">
> +	After attaching a new buffer, this request is used to describe
> +	the regions where the new buffer is different from the
> +	previous buffer and needs to be repainted.  Coordinates are
> +	relative to the new buffer.
> +      </description>
> +
> +      <arg name="x" type="int"/>
> +      <arg name="y" type="int"/>
> +      <arg name="src_width" type="int"/>
> +      <arg name="src_height" type="int"/>
> +      <arg name="dst_width" type="int"/>
> +      <arg name="dst_height" type="int"/>
> +    </request>
> +
>      <request name="frame">
>        <description summary="request repaint feedback">
>  	Request notification when the next frame is displayed.  Useful

Hi,

damage is supposed to be given with any number of damage requests, and
the resulting total damage for a frame for a surface is the union of
the sent rectangles, just like pixman regions are (and that is how they
are implemented).

Given that, I don't think your proposal for damage2 makes sense. I
didn't check your implementation patch too well (watch out for spaces
vs. tabs).

Let's say I use damage2. I have three sub-rectangles of my new buffer
that changed compared to the previous buffer. I send those three
sub-rectangles using damage2, and... do you see the problem, even
without any scaling? And then if I scaled each of my sub-rectangles
differently, I have no idea what could or should happen.

Therefore damage request is not the right place for this. The
wl_surface::attach might be.

I understood you want the surface size to differ from the buffer size.
In the current protocol, surface size is dictated by the buffer size
during attach. The logical place to implement your feature is to add
width and height parameters to the wl_surface::attach request, to
define the surface size regardless of the buffer size.

Then you need to clearly define in what coordinate system (buffer vs.
surface) damage, the x,y parameters to attach, etc. are given. This
applies to all protocol that uses surface-local coordinates, so pretty
much everything. I guess the sane thing would be to say that everything
is in the surface coordinate frame, not in the buffer coordinate frame.

You might also need to define something about the scaling. Is clipping
instead of scaling allowed, if scaling happens to be very expensive?
Can we demand anything from the scaling quality? Is nearest-pixel
sampling allowed?

There is yet another option: make this surface scaling a (shell?)
protocol extension feature, instead of core protocol. I'm not sure how
that would work, though, it might be even more trouble.

Finally, there is one thing I have not commented on: are scaled surfaces
as defined here for better or worse? That I cannot say.


Thanks,
pq