High DPI issues

[Teo Mrnjavac]

On Tuesday, May 20, 2014 15:16:25 Teo Mrnjavac wrote:
> On Tuesday, May 20, 2014 14:55:16 David Edmundson wrote:
> > On Tue, May 20, 2014 at 2:28 PM, Teo Mrnjavac <teo at kde.org> wrote:
> > > Hello,
> > > 
> > > I've had a chat with Morten Johan Sørvig, the person behind the high DPI
> > > effort in Qt. What follows is a status report.
> > > 
> > > The work on high DPI support that's already merged is focused on OS X
> > > and
> > > iOS, but it's mostly cross-platform code. There's also some unmerged
> > > work
> > > on other platforms.
> > > The X11 implementation of the scaling feature would rely on an
> > > environment
> > > variable QT_HIGHDPI_SCALE_FACTOR, leaving it to the workspace to set
> > > this
> > > value to something sensible (also described in [1]).
> > 
> > That means it's fixed as one global scale factor instead of one per
> > screen.
> > Given the API is all there that's a bit rubbish.
> 
> The QT_HIGHDPI_SCALE_FACTOR could also be per-screen, we can arrange that,
> but it makes our heuristics and/or settings more complicated. I'm guessing
> we'd have to at least move the DPI override setting from the Fonts KCM to
> KScreen.
> > I'm not sure how else one could do it in a X-platform way. Maybe this
> > is worth a talk with Gnome, Ubuntu and whoever else pretty soon.
> 
> It seems like Xorg people don't even want to talk about this, judging from
> those bug reports I linked earlier.
> Based on a quick search and skim through [1], Gnome 3 seems to go the X way,
> i.e. hardcoding 96ppi and using its own scaling factor set in dconf
> (org.gnome.desktop.interface text-scaling-factor). I don't know if they
> have heuristics to try to come up with that number automatically.
> Ubuntu/Unity, no clue.
> Sure, we can try to talk to people.
> 
> > > Another important issue is that currently the only tested and nicely
> > > working values for QT_HIGHDPI_SCALE_FACTOR are 1.0 and 2.0, i.e. Mac OS
> > > style scaling.
> > 
> > I can't imagine it being too big a problem; things only look bad once
> > they're past a certain point.
> > 
> > > produce decent results and minimize glitches, but the only way to be
> > > sure
> > > of that is trying it out. I'll try to give his branch a spin when I get
> > > the chance.
> > 
> > Please do, and report back.
> 
> Will do.
> 
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=643704
> 
> Cheers,

High DPI status update, part 1.

I've taken the liberty of investigating what some other environments do for UI 
scaling on high DPI devices, here's what I learned about Ubuntu.

TL; DR: they are focusing on their own desktop/tablet/phone shell. Their QML-
based tech already includes their own scaling system, different from the one 
in GNOME or the one Qt will get. Interoperability with the traditional Linux 
desktop is not a priority.

Long version follows, courtesy of Michael Zanetti.

> So, we're using a concept called grid units. Basically its nothing else than
> a scaling factor, but instead of taking 96 DPI as 1 and then scale
> everything up by lets say 1.8 we're defining 1 as the one grid unit in the
> checkerboard you might know from design mockups. You know if you get images
> from a designer with all those grey squares on it. This way we have not
> only a defined measure for coders, but also a language to talk to our
> designers and know that we're meaning the same thing. On 96 DPI, 1 GU
> equals 8 Pixel. On my Retina Mac I'm using 18 pixels per grid unit.
> 
> 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/resolution
> -independence.html
> 
> Another thing, not listed in this document is how we handle images:
> When writing an app and you want to ship an image, say foo.png, you can ship
> multiple versions of that image. E.g. foo at 8.png, foo at 16.png and foo at 20.png.
> Our QML image provider will then automatically figure the grid unit settings
> and pick the closest available (or one that can be scaled with the best
> results and least quality loss) and put that into the ui.

While it's unfortunate that this doesn't leave much room for cooperation, 
their strategy might make sense for their own goals.
When QtWidgets with scaling factor support is released they might have to 
convert their scaling factor to Qt's for interoperability.

Either way, it seems that whatever Ubuntu is doing for scaling is increasingly 
moot for us, especially with Qt getting its own scaling mechanism.

Part 2 coming soon, with the current state of things in the qt5-qtbase-hidpi 
branch and screenshots.

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