[Development] Scalable UIs in QtQuick (take 2)

[Sorvig Morten]

> On 19 Feb 2016, at 10:44, Gunnar Sletta <gunnar at sletta.org> wrote:
> 
> 
> 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.

The alternative is that the scale factor needs to be propagated upwards: into styles, layout specifications, animation velocities, etc. I’m not sure this is dramatically less error prone overall.

For shaders and blurs: the inputs needs to be scaled, right? The algorithms themselves run entirely in device pixel space.

I agree that code that deals with both logical and actual pixels tend to become complicated. We should seek to minimize this as much as possible.

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

However the failure mode for many, if not most, of these bugs is good: you get pixelated/blurry graphics instead of tiny UI elements and broken layouts.

So I think you are overstating the brokenness a bit. We had Qt Creator running and looking good almost from day one, see the April 2013 screenshot of X11 Creator at goo.gl/8h1d4q.

>  
> 
> 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 :)

But now the application code still has to deal with two coordinate systems, and there is no compatibility for legacy / dpi-unaware code. Are we sure there would be less bugs? Except that maybe the bugs are moved from the Qt code base to the application code bases.

In addition we'll have a different set of bugs in Qt that needs to be fixed: hardcoded pixel values like the velocities in quickflickablebehavior_p.h now needs to be scaled by he target display DPI.

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

We agree on this point, except that the devicePixelRatio approach has pixelSize meaning logical pixels :)

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

At the very least the current solution should be recognized as an “alternative solution" and not labeled a “mistake”.

- Morten