[Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> 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.

Morten

http://stackoverflow.com/questions/3166501/getting-the-screen-density-programmatically-in-android
https://groups.google.com/forum/#!msg/android-developers/g56jV0Hora0/9d8p8QJg1ksJ