[RFC v2] surface crop & scale protocol extension

[Pekka Paalanen]

On Thu, 14 Nov 2013 12:27:22 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> Pekka Paalanen wrote:
> 
> > Yes, you cannot use non-integer surface sizes. You cannot express a
> > surface size, that would result in a 1024x1024 area in output pixels,
> > because 1024 is not divisible by output_scale=3.
> 
> Thanks. That is indeed exactly the problem I am concerned about.
> 
> > This limitation exists also before crop & scale. Crop & scale cannot
> > remove this limitation, because the whole Wayland protocol has been
> > built on surface coordinates and especially surface sizes are integers.
> 
> I thought the proposed crop+scale used fixed point to specify the 
> destination rectangle, which is a solution. I don't like it but I 
> thought it was done on purpose for this.

If you read the proposal, it does not, exactly because it was written
in the way that the destination rectangle size becomes directly the
surface size, and hence it must be integers.

The source rectangle is in wl_fixed_t.

> The buffer size sent with attach is also in buffer pixels. So a client 
> can make a surface any size. But because the offset is in "surface 
> coordinates" they cannot resize the origin corner except in multiples of 
> buffer_scale. However they *can* resize the opposite corner in pixels. 
> This seems pretty inconsistent and it would be nice to fix it too.

Buffer size is the property of a wl_buffer. The size is not explicitly
sent on attach. You are right about the offset.

Clients cannot "resize the opposite corner" in the way you
assume, because the protocol requires that the buffer size is a
multiple of buffer_scale, so that it always results in a surface size in
integers.

Buffer size must always be a multiple of buffer_scale. That was defined
when buffer_scale was added to the protocol.

So, there are two different cases for surface size:
1. Crop & scale not used: surface size is determined from buffer size
   via buffer_transform and buffer_scale.
2. Crop & scale is used: surface size is directly dst_width,dst_height.

In both cases, surface size is guaranteed to be in integers.

Surface size is always in integers. Nothing I have proposed, or in the
current protocol, allows otherwise.

- pq