[PATCH 1/4 wayland] add damage2 api

[Zhao, Halley]

Hi pq:
Thanks for your review, I have updated the patches to use wl_surface_attach2().

I agree to your definition of coordinate: all protocol uses surface local coordinates, buffer coordinate is only used for (sub-)texture mapping inside Weston.

Since opengl and overlay supports scaling in nature, I think there are only some corner cases that scaling are not supported.
Opengl and overlay have their interface to control scaling quality, should we create such interface per wl_surface or a global one for Weston?

Next, I can try to add interface for the above two.



> -----Original Message-----
> From: wayland-devel-bounces+halley.zhao=intel.com at lists.freedesktop.org
> [mailto:wayland-devel-
> bounces+halley.zhao=intel.com at lists.freedesktop.org] On Behalf Of Pekka
> Paalanen
> Sent: Thursday, June 07, 2012 2:53 PM
> To: Zhao, Halley
> Cc: wayland-devel at lists.freedesktop.org
> Subject: Re: [PATCH 1/4 wayland] add damage2 api
> 
> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel