[Development] High-dpi Qt best practices

[Christoph Feck]

On Tuesday 09 October 2012 10:37:50 Sorvig Morten wrote:
> While preparing an upcoming blog entry I've collected some best
> practices regarding raster graphics (QImage and QPixmap). These
> apply to internal Qt development as well. The patch is still
> pending so they are open for discussion.

From what I know, OS X applications do not use something similar to 
QLayout. Widgets are positioned in absolute pixel coordinates, so they 
cannot adapt to different font sizes. To make it less of a burden to 
port those applications, Apple decided to keep the metrics, and let 
the OS scale them to larger pixels.

To be honest, I do not like the idea to introduce the same artificial 
scaling factor to Qt. Our layout system already adapts to different 
text pixel sizes automatically. The added API looks complicated and I 
am irritated where I have to apply a scaling factor, and where not. 
Additionally, it is not clear, if I have to multiply with or divide by 
that factor.

Examples:
Lets say I want to draw text to a high resolution pixmap. What should 
I be doing? Does fontMetrics.height() return physical pixels or 
artificial points? Do I have to multiply the font point size, or use 
the font size the user has configured unmodified? What if I place text 
besides a pixmap that has text rendered into it, i.e. how can I make 
sure they are equally sized? How does font.setPixelSize() work?

Can widgets be positioned exactly on high-DPI applications, not only 
in steps of 2 pixels (widget coordinates are integers)? This could 
introduce gaps, which can be visible even on high-DPI displays 
(imagine a white line between two black boxes).

What happens when I save() a pixmap to a file? Is the scaling factor 
kept in a way, so that loading it again results in pixel-identical 
resolution? Is the DPI reported by the file changed as well?

If I understand correctly, existing applications will automatically be 
upscaled by the Quartz compositor, so here we do (and cannot) change 
anything.

For new applications, that say they are aware of high-DPI displays, we 
want to address each pixel on the screen individually. To do this, the 
dimensions of pixmaps must be in pixels. How big they eventually 
appear physically on screen is controlled by the screen's DPI setting, 
which is also used to convert font point sizes to pixel sizes. 
Applications that want to use units such as "cm", need to query the 
screen's DPI setting anyway.

What I would be doing is this: For applications that say they are 
high-DPI aware, simply return the screen's DPI, which could be 144 
dpi, or even 384 dpi. For other applications, return a legacy DPI 
(e.g. half the value, depending on what scaling factor the compositor 
uses for legacy applications).

QStyle has functions to return different icon sizes, and the values 
they return should be bigger for aware applications. If the graphics 
supplied is not large enough, Qt should automatically scale it (as far 
as I know, it refuses to do it in current versions).

To me this sounds much less work to adapt an application. What am I 
missing?

Christoph Feck
http://kdepepo.wordpress.com/
KDE Quality Team