[Development] High-dpi Qt best practices
christoph at maxiom.de
Tue Oct 9 13:55:57 CEST 2012
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
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
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
KDE Quality Team
More information about the Development