[RFC v2] surface crop & scale protocol extension

[Bill Spitzak]

Pekka Paalanen wrote:

>> The source rectangle *must* be in buffer pixels. Putting it in 
>> buffer_scale units makes absolutely no sense, as the buffer_scale is in 
>> effect ignored for this surface, overridden entirely by the scaling.
> 
> That means that dst_width and dst_height will be required to be in
> multiples of buffer_scale.

I am rather confused about this and possibly misunderstanding what 
Wayland is doing. Here is an example of what I think the current design is:

Imagine there is an output_scale of 3 (chosen to not be a power of 2). A 
client is aware of this and wishes to draw a full-resolution display 
that is 2000x2000 pixels and make a subwindow that scales a 512x512 
picture to fill a 1000x1000 pixel square.

I think what that client does on Wayland under this proposal is this 
(please correct if wrong):

- It creates a 2000x2000 pixel buffer and draws everything including the 
1000x1000 frame into it. The surface is given a buffer_scale of 1/3 (or 
3 depending on how buffer_scale is defined, I am unclear on this).

- This is sent to the compositor. The compositor scales the buffer by 
1/3 to get "surface coordinates" and then scales it up by 3 to output 
space, but these cancel out to the identity. In "surface coordinates" 
the surface is 666.666 units square and the frame is 333.333 units square.

- The client also creates the 512x512 image for the subsurface and will 
use the scaling api. It sets the source rectangle to 0,0,512,512 pixels. 
If buffer_scale affects this the client is forced to set it to a power 
of 2, since 512 is not a multiple of 3.

- The destination is set in surface units and thus must be a rectangle 
333.333 on each side, and may have a fractional origin as well. This is 
done by sending the nearest possible fixed values and assuming the 
compositor will round to the correct pixel. Buffer_scale of the 
subsurface and parent have no effect.

My proposal is:

- The source rectangle is always in buffer pixels so it can be 512 no 
matter what the buffer_scale is set to.

- The buffer_scale *does* apply to the destination rectangle. The client 
would set the subsurface buffer_scale to 1/3 just like the parent (or it 
is inherited from the parent), and then the destination rectangle would 
be 1000 square, and the corner would be integers as well.

- (unrelated) The origin of the buffer attach is in buffer pixels so a 
surface can be translated by integer numbers of pixels.

> In my opinion, buffer_scale is not an issue either way. The issue is
> buffer_transform. Does buffer_transform apply to the buffer, or to the
> cut-out rectangle?

I personally would like all coordinates to be in actual buffer pixels, 
before the buffer_transform. However I think too much existing Wayland 
api, in particular the buffer width + height, are in the after 
coordinates and consistency is better.