[Development] Revisiting high-DPI configuration options

Michael Zanetti michael.zanetti at canonical.com
Wed Jun 22 15:30:52 CEST 2016

On 22.06.2016 14:46, Morten Sorvig wrote:
>> On 22 Jun 2016, at 10:30, Michael Zanetti <michael.zanetti at canonical.com> wrote:
>> On 20.06.2016 15:00, Morten Sorvig wrote:
>>> Another reason to not spend time on it would be that integer is, or is going
>>> to be, the dominating use case. Wayland and Apple is integer, so are most of
>>> the Android device categories. For Windows and desktop in general there are
>>> currently lots of fractional hardware and configurations.
>> I don't think this is true. From all the devices (phones/tablets) we
>> support Ubuntu on, none is a full integer multiplier. I really don't see
>> how it is going to fly if only full integers are supported. After all,
>> all the Ubuntu Devices are actually based on Android hardware, so surely
>> there the same issue would happen, no?
> What I have for Android devices are tables like this: (there are various
> sources, see below)
> 0.75 - ldpi
> 1.0 - dpi
> 1.5 - hdpi
> 2.0 - xhdpi
> 3.0 - xxhdpi
> 4.0 - xxxhdpi
> The factor here is DisplayMetrics.density. This suggests integer factors, or
> at least a convergence towards integer factors if we allow that new Android
> devices are xhdpi or better.
> It think what is happening is that the hardware may be non-integer, but then
> Android maps that to a device class with a fixed scale factor. We can use that
> scale factor in Qt - any error introduced by it (if the hardware is some fraction
> between classes) will be matched by the native UI.
> If Qt applications are going to see fractional factors on Ubuntu then that’s
> a point in favor of making Qt work better in that configuration.

Hmm, I see... So what we are using is this:

Nexus 4: 2.25
Nexus 7: 2.25
Nexus 10: 2.5
bq E4.5: 1.625
Meizu Pro 5: 2.625

Because of this we're currently not using the devicePixelRatio() API.
Instead, that one is set to 1 and we add an additional layer in our
toolkit on top. So we'd use units.gu(1) on the application level to
express 8 pixels on a scale factor of 1. That method then returns device
pixels based on the scale factor, rounding it to full integers after the
scaling. Those values are calculated in a way that we'd get as close as
possible to a consistent look and feel of the platform. For example, for
a 4 to 5 inch screen we try to have 40 grid units (units.gu(40)) in
width. 5 to 6 inch devices would have 50 grid units in width and so on.
This gives a rather consistent look and feel of the platform across
different sizes and pixel densities.

Using this method in our toolkit on top of Qt is obviously not ideal for
a (rather big) number of reasons and we *really* would like to drop this
in favor of the in-Qt high dpi mechanism. For that however, it would
need to match a number of requirements:

* floating point scaling
* different scale factor per window
* dynamically changing scale factor
* some sort of language that allows developers to use virtual sizes,
ideally we'd be able to register our grid unit stuff as that's what all
our design has evolved around.

I really think that in the mid to long run, all of those requirements
will become natural on all platforms. Now that people start connecting
external displays to their phones, or now that desktop monitors come
with different pixel densities, dragging a window from one screen to
another with a different pixel density will become something we
encounter more and more often.

Some more details on this can be found in an earlier mail on this topic:


Best regards,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160622/1a7f4456/attachment.sig>

More information about the Development mailing list