[PATCH 2/2] protocol: Support scaled outputs and surfaces

[Alexander Larsson]

On mån, 2013-05-20 at 13:56 -0500, Jason Ekstrand wrote:
> On Mon, May 20, 2013 at 4:00 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
>         On Thu, 16 May 2013 16:43:52 -0500
>         Jason Ekstrand <jason at jlekstrand.net> wrote:
>         
>         > The point of this soi is to allow surfaces to render the
>         same size on
>         > different density outputs.
>         
>         
>         Are you serious? Really? Same size measured in meters?
> 
> 
> No, measured in inches. :-P
> 
> 
> Seriously though.  While we can't make it *exactly* the same on all
> your displays, we should be able to make it usably close.

Having the exact physical size (be it in inches or steradians) of a
window on two different monitors is *not* a goal of my work. Its already
the case that windows are different sizes on different monitor, and that
has been ok for users since the first a CRT was used with a computer.
People have been bikeshedding about solving this "problem" for ages, and
I'm not interested in that.

No, I have an *actual* problem, which is that its super hard to see or
hit widgets on a high dpi monitor, and a single "DPI" setting for the
whole desktop is a nonstarter since you may be using mixed monitors.
This is a practical problem I have on my pixel laptop and which will
only get more common as hw moves on. The solution required is not exact
size matches, but rather "make it the same ballpark", which my proposal
solves in a very simple fashion.


> What I would like in the end is a per-output slider bar (or something
> of that ilk) that let's the user select the interface size on that
> output.  Sure, they probably won't be able to select *any* resolution
> (the compositor may limit it to multiples of 24 dpi or something).
> And they can certainly make an ugly set-up for themselves.  However, I
> want them to be able to make something more-or-less reasonable and I
> see no reason why the compositor shouldn't coordinate this and why
> this "scale factor" can't be used for that.

The compositor is free to scale the final result to any fraction it
wants, which will get you this kind of behavior. It will not be
"perfect", but the other solution (adding complexity of fractional
surface sizes, multiple coordinate spaces, etc) also will also not look
very nice (i.e. widget clipping on fractional coordinates will look
ugly, non-integer-width lines will *never* look good, etc), and in fact,
internal details makes it unlikely that toolkits like Gtk will ever be
able to support fractional scaling, so it has little practical use.