On 22.06.2016 14:46, Morten Sorvig wrote: > >> On 22 Jun 2016, at 10:30, Michael Zanetti <michael.zane...@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: http://lists.qt-project.org/pipermail/development/2016-February/024954.html Best regards, Michael
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
