[PATCH 0/2] Support for high DPI outputs via scaling
Alexander Larsson
alexl at redhat.com
Mon May 13 04:26:40 PDT 2013
On mån, 2013-05-13 at 12:40 +0200, John Kåre Alsaker wrote:
> The scaling factor should not have any affect of any coordinate system
> or anything else in the protocol. It should only affect the size in
> pixels of the surfaces of the clients. Clients should do any
> transformations of coordinates they want themselves.
I'm not sure if we agree or not here. But, lemme have an example. If you
have a setup with two monitors using mirrored mode, one with scale == 2.
Then I want both monitors to show the same thing, one with more detail.
If I then put the mouse cursor over the bottom right corner of the
surface i want to get one mouse event, and the coordinates of it should
be the size of the window in the unscaled coordinates, i.e. the
width/height of the window in the lower resolution.
Is this what you meant?
> Clients can easily scale larger features like icons, padding and fonts
> and round them to pixel sizes and draw sharp output even with a
> fractional scaling factor. This allows users to pick a size suitable
> for them. The difference between a 1 and 2 scaling factor is too huge.
Some things can be easily scaled. Like text and photorealistic images.
Other things can't necessarily be scaled and still look nice. Like line
art or solid line borders (like e.g. the boxes around a button). Sure,
you can round everything to "nearest int", but that will cause
unevenness in the rounding (buttons sometimes get a 1 pixel border,
sometimes 2 depending on the fractional part of the button coords, etc).
So, I don't think this is every useful in practice.
> I think the case when a window is displayed on multiple monitors is
> pretty rare or short in duration (the dragging across monitor case
> when not using a workspace per monitor). I suppose we could leave this
> up to the compositor.
Totally, i don't mean that the priority is useful for that case.
Normally clients should just pick the scale based on which output the
surface has the "most" pixels in. However, the one case where that
breaks is mirrored/clone mode, where two monitors show the same thing.
This is where the priority can be useful.
More information about the wayland-devel
mailing list