[Development] resolution independence (was Re: Retina display support)

Wed Oct 3 00:10:10 CEST 2012

Am 01.10.2012 11:57, schrieb Rutledge Shawn:
> On Sep 21, 2012 w38, at 10:37 AM, ext Ziller Eike wrote:
>>
>>>> but that would be a huge waste of system resource and performance
>>>> drag when running on non-retina system. Are there any better solutions?
>>>
>>> Aren't you seeing the window size in pixels as usual? With that
>>> available, you would have a generic answere for your kind of question.
>>
>> Well, no. "Pixel" in the Qt world atm means something different than
>> "pixel" in the physical world (when talking about Cocoa / Mac).
>> The integer coordinates in Qt actually are mapped to what Cocoa calls
>> "points" which is referring to "logical" coordinate space, not
>> "device" coordinate space.
>> A HiDPI screen has the same number of "points" as a corresponding
>> non-HiDPI screen, but it has a "scale" (of 2). Applications see the
>> same number of points when they run on a HiDPI screen as they would on
>> a non-HiDPI screen (--> everything has exactly the same physical
>> dimensions when running on different screens).
>> That means that Qt also reports the same dimensions. Rastering for
>> pixmaps is also done based on "points".
> 
> That distorts the definition of "pixel" rather more than one would expect.
> 
> Here's how it's supposed to work (how it already works on Linux and
> Windows):  QScreen reports both the logical and physical DPI, and the
> documentation already states that logical DPI determines the size of a
> "point" for fonts.  The physical DPI is calculated as the ratio of the
> configured resolution to the physical dimensions of the screen (as
> reported over the DDC connection from the monitor).  Logical DPI can be
> overridden in the operating system (in the display control panel, or on
> Linux, in xorg.conf or by giving a parameter when starting X).
>  Overriding the logical DPI is the normal way for people to "zoom" the
> screen, for example to get larger fonts if one's vision is impaired.
>  (Or else, people who don't know better might just change the resolution
> and let the scaling hardware zoom it up to fit, which will have a
> similar effect on logical DPI, but makes it blurry too.)  On pre-OSX
> Macs, 72 DPI was normal, and was relatively constant if you bought Apple
> displays.  But in more recent times 96 DPI has become normal.  So I
> think a logical pixel should be defined as whatever the user or the OS
> sets it to be, by setting the logical DPI.  (Maybe Qt could have a
> configurable limit though, in case the OS doesn't provide a way to
> override the logical resolution.)

I can only add that the reported physical dpi for windows are not the
real physical. They report what the user has set in windows for it, or
better to say it defaults to 96 dpi. There seems to be no api from
windows to find out the actual api, in x11 you are able to get it
somehow with some head stands. I also know that it is not so easy in mac
os x to get it. So very unpleasant these days of touch times. Really sad.
In windows I found a very ugly way to determine the dpi of a screen,
where I did a implementation for kde:
http://quickgit.kde.org/index.php?p=kdepim-runtime.git&a=blob&h=8a17d1d77ae22022cc5436a49cb7be7fa1fe8145&hb=b68e55a2eedd410b9c6a8ca1df63276afe18afe2&f=qml%2Fkde%2Fkdeintegration.cpp
This looks in the registry for the copied edid data of the physical
display and then decodes its physical screen size.

> 
> QScreen on OSX currently has a hard-coded definition of DPI, 72 pixels
> per inch.  This is not accurate on any modern hardware, and I'm planning
> to change it to report actual resolution and logical resolution, just
> like the other platforms.  There are already HiDPI non-Apple displays,
> for example this from 2009:
>  http://techreport.com/news/16181/sony-intros-wide-expensive-vaio-p-netbook
>  which has an 8" display with 1600x768 resolution.  If you run Linux or
> Windows on it, I expect that QScreen will tell you the actual
> resolution.  Qt is supposed to be cross-platform, so it doesn't make
> sense to do something completely different on OSX only.
> 
> Likewise the idea that HiDPI displays are always "2x" seems to me
> another inelegant hack.  Actually the DPI varies between devices, so
> high-resolution art should not always need to be exactly 2x the normal
> size.  It may be convenient, but it's not the kind of "solution" we can
> expect to last very long.  I wouldn't be surprised if Apple themselves
> changes their tune later.
> 
> I think for the sake of true resolution independence, we need to extend
> QML to have support for units.  E.g. you should be able to specify
> 
> Rectangle {
> width: 20mm
> height: 10mm
> Text {
> font.size: 5mm
> text: "Hello World"
> }
> }
> 
> font.pixelSize and font.pointSize could even be deprecated then, because
> every supported unit would be OK for every possible dimension: pixels
> (which would probably be logical pixels), millimeters, points, inches,
> etc.  (Maybe we could also have "rpx" or some such to represent actual
> pixels rather than logical pixels.)  The fact that it's a change to the
> language makes it nontrivial, but at least it's the same as what CSS
> does, and QML was designed to be similar to CSS, after all.  Then we can
> claim that we have true resolution-independence.  You could specify a
> rectangle as above, and measure with a ruler on the screen, and it
> should be exactly 2 x 1 cm on every device, as long as the device
> reports its own screen resolution accurately.  It would be the same if
> you print it.  When you are creating a UI, if you want exact sizes you
> could use real-world units, whereas if you want a UI which is scaled in
> proportion to the user's system-wide wishes, you would use logical pixels.
> 
> But then it would also make sense to extend the Javascript
> implementation too, so that it's possible to assign numbers with units.
>  As soon as such unit-value types exist, one begins to think it should
> be possible to do math with them too, and have transparent unit
> conversions whenever necessary.  It would be really cool, but it's
> all-new territory for Javascript (although it has been done before in
> some math-oriented languages).  As a stop-gap until the JS extension is
> done, maybe you could still assign a plain number to a unit-value
> quantity, in which case only the number is changed while the units
> remain the same.
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

-- 
Andreas Holzammer | andreas.holzammer at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2898 bytes
Desc: S/MIME Kryptografische Unterschrift
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121003/17d6a02c/attachment.bin>