[Development] Scalable UIs in QtQuick (take 2)

[Gunnar Sletta]

> On 18 Feb 2016, at 13:05, Sorvig Morten <Morten.Sorvig at theqtcompany.com> wrote:
> 
>> 
>> On 18 Feb 2016, at 12:35, Nikita Krupenko <krnekit at gmail.com> wrote:
>> 
>> 2016-02-18 12:50 GMT+02:00 Hausmann Simon <Simon.Hausmann at theqtcompany.com>:
>>> (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping.
>>> 
>>> (2) In the events where you still _want_ to use physical pixels, you could use "px" units.
>>> 
>>> So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But
>>> if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm.
>> 
>> Isn't (1) already done with Qt::AA_EnableHighDpiScaling? Though
>> disabling this feature for some items would be useful, like for
>> Canvas, which is broken now with this scaling.
> 
> This is indeed what is done for that flag and on OS X and iOS. In that
> sense logical pixels are already supported.
> 
> “px” could be added, but what are the use cases? You almost never want to
> have small content on high-DPI display. I see doing custom scaling in the 
> application as a possible one.

One obvious usecase which always comes back to haunt is when those logical units need to be translated to actual pixels, such as when dealing with graphics. Up until some time ago, Something::size() was enough to decide the pixel dimension of things. Now every piece of code needs to also know about device pixel ratio and that needs to passed down to image loaders, icon generators, texture produces, shader effects, blur algorithms, autotest-screengrabbers, etc. It is rather error prone.

We've had probably hundreds of bugs in Qt over the last few years in various corner cases where the DPI has to be carried along to make the size into the actual size, and people still are running into them on a regular basis. And this is a bug chase that will never stop because users will always run into cases where they thought carrying the size was enough, but also need the DPR. 

If the objects operated in pixel sizes, the problem could be solved centrally once and for all. There are plenty of ways, as long as we don't violate that princible. Options include theme specific pixel sizes, using "units" in QML that end up being "blah cm" -> "blah * 32" in practice, where units can include arcseconds, points or physical sizes. Using a global scale factor to pixels ratio that is applied in QML before passed to objects is also fine, using percent of parent/sibling. Either one is a valid option, but the values we pass to our graphical objects, like Rectangle {} and Canvas {} and the values Item::width() report back should be in actual pixels, same with the values we pass to QQuickImageProvider and every were else. The logical scaling is something that happens in the app in QML. Otherwise, the bug tirade never ends :)

(And to avoid the additional confusion, we should probably avoid having Font.pointSize, so that fonts operate in the same coordinate space as the other objects. The pixel size of a point should be accessible through other means when required).

It has been deemed too much work to fix widgets and styles, but Qt Quick doesn't need to commit to the same mistake.

cheers,
Gunnar

> 
> As a minor platform note, “px” would not be guaranteed to be physical pixels
> on Apple operating systems. There can be further resolution virtualization,
> for example when setting a scaled resolution for the display.
> 
> Morten
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development