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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
