> On 18 Feb 2016, at 13:05, Sorvig Morten <[email protected]>
> wrote:
>
>>
>> On 18 Feb 2016, at 12:35, Nikita Krupenko <[email protected]> wrote:
>>
>> 2016-02-18 12:50 GMT+02:00 Hausmann Simon <[email protected]>:
>>> (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
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
