High DPI issues

[Teo Mrnjavac]

On Monday, May 26, 2014 17:06:12 Sebastian Kügler wrote:
> On Monday, May 26, 2014 16:55:42 Teo Mrnjavac wrote:
> > > Now, the most important difference to the approach I've seen in Qt, is
> > > that
> > > this is a QML binding in our case instead of a scaling factor which you
> > > inject in the rendering engine. This means, we can change those not only
> > > on
> > > runtime, but have different settings for different parts of an
> > > application.
> > > Think of an application with 2 windows, one on your old school monitor,
> > > the
> > > other on your retina screen. We could adjust those depending on which
> > > screen you're running, even inside the same application.
> > > 
> > > 
> > > 
> > > The official docs for this can be found here:
> > > http://developer.ubuntu.com/api/devel/ubuntu-12.04/qml/ui-toolkit/resolu
> > > ti
> > > on -independence.html
> 
> Note that they actually got this wrong: They're not using a binding but an
> invokable, meaning that gridUnit changes aren't propagated automatically,
> but need to be triggered for re-evaluation. This looks like an API problem
> to me, so it's not easily fixable for them (without changing the API).
> 
> We've introduced gridUnits in Plasma as well, and are using them throughout.
> The difference with Ubuntu's implementations are:
> 
> - They're notifiable properties in Plasma. so you'd write units.gridUnit *
> 2, not units.gridUnit(2), that's the fix for the above problem.
> 
> - gridUnit depends on the fontsize-as-rendered in Plasma, not an arbitrary
>   scaling factor (Michael isn't clear on where they get this factor from)
> 
> Bottom line is that the Ubuntu gridUnits stuff can very easily be ported
> (both ways), but Plasma's mechanism is at a higher level.

I've just heard back from Florian Boucault of Canonical.

As far as I understand, Florian is the go-to person for scaling issues in the 
Unity team, and also a fan of KDE and Plasma (yay!). He's kindly providing 
some more information on their scaling mechanism, quoted below.

> The official documentation for the resolution independence system in Ubuntu
> apps is at:
> http://developer.ubuntu.com/api/qml/sdk-14.04/UbuntuUserInterfaceToolkit.re
> solution-independence/
> 
> The goals we had in mind when designing the system were:
> 1) preserving the perceived size of all UI elements the same regardless of
> the distance the user is to the device and regardless of the device's
> screen density
> 2) making UIs look better without extra effort by:
>    - making it trivial for developers to implement exactly visual
>    designs/mockups without wasting time asking for exact measurements or
>    sacrificing pixel perfectness
>    - having UI elements tend to align
>    visually more together
> 
> At the end we settled with 2 units:
> 1) The unit everybody knows: the virtual pixel, also called CSS pixel or
> point in the Apple world. It is the size of the screen's pixel if the scale
> factor is 1 and is generally simply proportional to the scale factor. We
> call it "dp" to be consistent with Android. We recommend to not use this
> unit if you can avoid it. With the latest resolution independence patches
> in Qt, it is also redundant with the regular pixel unit you are accustomed
> to in QML.
> 2) A unit called "grid unit" that is by definition exactly 8
> virtual pixels. We recommend using that one as it implicitly helps having
> UI elements aligned since there is simply less grid units available on any
> given screen.
> 
> Backend wise we store the equivalent of the scale factor in GSettings/DConf
> under the schema " com.ubuntu.user-interface" with the key " scale-factor".
> It contains the current definition of the grid unit in pixels _per_
> monitor. We use that not only for our QML toolkit but also for GTK and the
> other "legacy" toolkits used in Ubuntu. Note that to go from the definition
> of the grid unit in pixel to a more standard scale factor, it is a simple
> division: scale_factor = grid_unit_px / 8
> The definition of a grid unit for
> a given monitor is done manually using a formula for a first approximation
> and then fine tuning it with the trained eyes of the designers. We are
> slowly building a database associating monitors with their grid unit
> definitions.

My 2¢: the part about having a database of monitors seems very ambitious but 
might be useful for our own guessing magic some day; and it turns out there's 
at least some compatibility with "legacy" GTK applications, so I guess that's 
good.

Cheers,
-- 
Teo Mrnjavac
http://teom.org | teo at kde.org