[wayland HiDPI support, posible regression?]

[Bill Spitzak]

I think he did not explain the problem exactly. Pixels in the buffers 
themselves can be hi-dpi.

The problem is that the wayland api still has several integers that are 
in "low-DPI" pixels. The buffer size, the xy offsets when the buffer is 
set, the position in the subsurface api, the destination rectangle for 
the subsurface scaling, and all the regions such as the input region are 
in these larger units. This artificially restricts the graphics a 
Wayland client can draw such that various items can only be positioned 
on the larger pixel boundaries. It is true that the adjustments are very 
small, but this sort of limitation is incredibly annoying when writing 
clients. as this rounding information must be passed to very low-level 
graphics routines.

It would be api-breaking but I think all integers sent from clients to 
the server should be in buffer pixels.

There is a convincing argument that events need to contain lo-dpi units, 
because the client is allowed to change the scale of the buffer during 
an attach, and this avoids the need to figure out which buffer attach an 
event is for. The ideal solution would be to provide the scale with the 
events, but it is probably easier to use the 24.8 fixed-point and assume 
clients will always do round-to-nearest when they convert back to 
pixels, since 24.8 is already being used in many events.

On 03/09/2015 08:59 AM, Jasper St. Pierre wrote:
> You misunderstood what pq said.
>
> You work in "logical pixels". On a hi-DPI display, with twice the pixel
> density, each "logical pixel" is backed by 4 device pixels. Your actual
> backing surface containing the pixels is in "device pixels".