Alexander Larsson wrote:
You can make a surface of any integer size (and it has to be integer due to existing APIs on surface coordinates/sizes), however the *buffer* has to be an integer multiple of the surface size. In other words, surface sizes and positions are described in the global compositor space, with integer sizes.
This seems pretty limiting to me. What happens when *all* the outputs are hi-res? You really think wayland clients should not be able to take full advantage of this?
If nothing else it makes it so that subsurfaces are always positioned on integer positions on non-scaled displays, which makes things easier when monitor of differen scales are mixed.
This is false if the subsurface is attached to a scaled parent surface.
I see it the other way. We currently have *two* coordinate spaces that the client has to think about. The buffer coordinates (it has to know this when rendering), and the surface coordinates (these are basically what all wayland APIs atm use, like in damage, positioning and input). The transform between two is currently the buffer_transform only. With the buffer_scale the transform is extended to also scale, but no additional coordinate space is added.
The input rectangle to the scaler proposal is in the space between the buffer transform and the scaling. Therefore there are *three* coordinate spaces.
My proposal is that "surface space" be moved before the scaling. This reduces the number of spaces back to two by using the same space for input rectangle as for events and surface size, etc. It also means integers always have a physical meaning for the client (ie buffer pixels) and that odd-sized buffers are supported on the hi-res display.
The number of spaces could be reduced one more by moving everything to before the buffer_transform. However this would change existing wayland api.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
