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

Alexander Larsson alexl at redhat.com
Wed May 22 01:33:04 PDT 2013


On ons, 2013-05-22 at 09:11 +0300, Pekka Paalanen wrote:
>  
> > 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.
> 
> I think that is an orthogonal issue. That would be a DE thing, just
> like choosing font sizes. Buffer_scale OTOH is a Wayland core feature,
> and is best kept as simple as possible.
>
> The slider would control window and widget sizes, while buffer_scale
> only controls the resolution they are rendered in. Or...

This is doable, but slightly problematic as you would need a way to
coordinate between all clients how to combine these...

> > My primary concern is that integer multiples of 96 DPI isn't going to be
> > enough granularity.  I don't know whether we can really accomplish a higher
> > granularity in a reasonable way.
> 
> For the cases where buffer_scale cannot offer a usable resolution, we
> can still fall back to arbitrary scaling in the compositor by
> private surface or output transformations. That does not allow
> pixel-accurate/high-resolution presentation of windows like
> buffer_scale, but I believe is an acceptable compromise. Didn't OS X or
> something do similar for the 1.5 factor? I recall someone mentioning
> about that, but couldn't find it.

So, in practice I think this is the more reasonable way to do it, and it
is indeed how OSX does it. In some theoretical way doing it by drawing
at 2x and downscaling to 1.5x is looks "worse", but neither is going to
look really "good" anyway, and the integer surface scaling makes the
implementation vastly simpler.

> Naturally the units in slider would be scaling factors, not DPI, since
> DPI is meaningless to a user. I can imagine how hilarious it would be
> to have "Please, try to use integer multiples of 96 DPI for the best
> performance and look" in the GUI. ;-)

I don't think a slider for scaling factor is the right UI at all. What
you want is to just list various "resolutions" and let the user pick
one. Some resolution are native, some are scaled by an integer and some
are scaled by an fraction. You want to somehow mark out in the UI that
some resolutions are "worse" than others, but otherwise this is
generally how most end user would think of this anyway.




More information about the wayland-devel mailing list