[RFC] wl_surface scale and crop protocol extension

[Pekka Paalanen]

On Thu, 2 May 2013 14:43:38 -0500
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Thu, May 2, 2013 at 1:22 PM, Daniel Stone <daniel at fooishbar.org>
> wrote:
> 
> > Hi,
> >
> > On 2 May 2013 15:42, Jason Ekstrand <jason at jlekstrand.net> wrote:
> > > Ok, I see it now. Sorry, but I missed it on my first
> > > read-through.  Yes,
> > it
> > > fixes the problem, but in an extremely confusing way.  The reason
> > > I say
> > it
> > > is confusing is because it inherently mixes buffer and surface
> > > coordinate systems.  I really think we need to isolate buffer
> > > coordinates from
> > surface
> > > coordinates more.  Perhaps what we need is two requests:
> > > set_source_rect
> > and
> > > set_dest_rect and completely ignore the x and y from attach.
> > > This both provides clarity to the coordinate systems and provides
> > > a little
> > separation
> > > between crop and scale.

Yes, this little rough corner bothered me, too. I tried to weasel out
of it by saying that wl_surface_scaler and wl_surface.attach must be
used together, so you can use the right values.

While we still use x,y from wl_surface.attach, nothing else really
makes sense. The x,y must be in the surface coordinate frame.

Since surface coordinates were equal to oriented buffer coordinates
(see my email sent just before this one), I think we could still change
the wording for wl_surface.attach specification to talk about surface
coordinates instead of buffer coordinates. Would that solve your
concern?

> > Ideally, when wl_surface::commit was added, wl_surface::attach
> > should've been broken out into wl_surface::attach and
> > wl_surface::set_position.  Oh well.
> >
> 
> Exactly.  That's what my suggestion was trying to fix (at least in the
> transformed surface case).

Would that really have made any difference? Clients would still be able
to use the x,y regardless, and we need to specify how they interact with
wl_surface_scaler.

> > That being said, we can't ignore the x and y from attach, because
> > that _moves the window_ on screen (think resizing from top left),
> > whereas this is all about how we map the contents of a buffer into
> > that window
> > - totally unrelated to moving.
> >
> 
> Yes, I realize that the x and y from attach are used for moving or
> scaling from top or left.  My suggestion was to replace the x and y
> in attach with an x and y in set_dest_rect.  We wouldn't be losing
> functionality, just moving it in a certain case.  This way surface
> coordinates are kept with surfaces and buffer coordinates are kept
> with buffers.
> 
> In this case, the defined behavior would be that if you create a
> scaler for a surface, the x and y in attach are disabled and
> set_dest_rect takes over.  This way older clients can just use attach
> like they used to and clients that use surface scalers use the
> destination rectangle.  It's not a perfect fix, but I think it moves
> in the right direction.  And, for what it's worth, it doesn't make
> things significantly more complicated because anything that's going
> to scale from the top-left will have to mess with both the surface
> and the scaler anyway.

Yes, that would be one option, and it would support the "I am forcing
that other component's surface size" better, since nothing in
wl_surface would affect what is set in wl_surface_scaler anymore.
Except the wl_buffer size, but if we *really* want to go that way, we
could say that areas outside of a buffer are transparent.


Thanks,
pq