Fractional scaling is a way of scaling user interfaces that allows for non-integer scaling factors. In order to support multiple displays with different fractional scaling factors properly and prevent size mismatches in all relevant situations, multiple coordinate spaces need to be used. This commit adds a protocol that adds the ability for compositor and client to change the coordinate space of their communication for that purpose.
I opted to make all coordinates be scaled, including input, to have all of them still be in a unified coordinate space and possibly reduce some confusion. Because it shouldn't matter in practice though, if anyone prefers to not scale input, I'd be willing to change that as well.
Advantages of this approach:
- toolkits can adopt the protocol without breaking any compatibility with clients, assuming they have any existing support for fractional scaling. This is especially relevant with "toolkits" like Wine, where neither API nor clients will adapt to Wayland
- coordinates are still commutative, meaning that all calculations regarding positions and sizes stay simple and intuitive
- clients can position subsurfaces on a granularity of one pixel
- compositors can request surface sizes with a resolution of one pixel, ensuring that there are never gaps between toplevels without requiring additional logic
- not directly an advantage of the protocol but still: compositors implementing this can easily provide the option to change the scale per client
Disadvantages of this approach:
- compositor implementations must use either floating point coordinates or pixel coordinates to ensure 1:1 pixel mapping
- compositor implementations must transform between their internal coordinate space to client coordinate spaces
Signed-off-by: Xaver Hugl xaver.hugl@gmail.com
cc #47 (closed)
Implementations: