Re: [Development] Revisiting high-DPI configuration options

[Randall O'Reilly]

I migrated to Qt from InterViews: 
http://www.ivtools.org/ivtools/doc/refman3.1/index.html  which used 
floating-point units that could be arbitrarily rescaled, but default to points, 
like many other standards (e.g., SVG, Postscript).  I always found it strange 
that Qt used integer pixel coords.  Seemed like a very time-limited solution 
even back in the day in terms of rendering to a printer vs. a screen, and 
anticipated increases in screen resolution which are now (finally) happening.

Seems like it might be time to do a global replace int -> float and just fix 
the “standard” meaning of the coordinate system in terms of points, given that 
it is probably pretty close to the pixel density of the “classic” displays that 
Qt was developed on, and it is used in these other standards, and existing apps 
should probably perform reasonably well with such a definition.  But internally 
support an arbitrary floating-point scaling factor so people can use whatever 
coordinate system they want going forward.  It just seems like any other 
solution is going to end up being a dead-end for future displays, and rather 
ugly in any case (as the current solution is demonstrating).

Also, another nice thing that InterViews got right was a multi-pass layout 
algorithm that “just worked” to best fit elements in available display spaces — 
including the option of using a LaTeX-inspired layout algorithm.  You specify 
“natural” sizes and flexibility factors, and the algorithm optimizes from 
there.  This works well when moving away from having to do precise layouts in 
pixel coordinates.. 

- Randy

> On Jul 26, 2016, at 8:56 PM, Nikita Krupenko  wrote:
> 
> 2016-07-27 4:02 GMT+03:00 Thiago Macieira :
>> Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko
>> escreveu:
>>> In Material Design guidelines [1] all font sizes are in scaleable
>>> pixels (sp). So this size could be multiplied by some factor and all
>>> fonts should scale equally.
>> 
>> Maybe we should instead use a size calculated in physical units, like 1/72th
>> of an inch. Oh, we have such a unit: points.
> 
> The idea of scaleable pixels is somewhat different: user can select
> big/small fonts in the OS/application settings and font sizes would be
> multiplied by some factor, for example 1.5.
> 
> BTW, why use font size in points? As other elements, like widgets,
> images, etc has size in pixels, it's better to use pixels for fonts
> too. Auto HiDPI scaling in Qt works for font sizes in pixels.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Thiago Macieira]

On quarta-feira, 27 de julho de 2016 05:56:52 PDT Nikita Krupenko wrote:
> 2016-07-27 4:02 GMT+03:00 Thiago Macieira :
> > Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko
> > 
> > escreveu:
> >> In Material Design guidelines [1] all font sizes are in scaleable
> >> pixels (sp). So this size could be multiplied by some factor and all
> >> fonts should scale equally.
> > 
> > Maybe we should instead use a size calculated in physical units, like
> > 1/72th of an inch. Oh, we have such a unit: points.
> 
> The idea of scaleable pixels is somewhat different: user can select
> big/small fonts in the OS/application settings and font sizes would be
> multiplied by some factor, for example 1.5.
> 
> BTW, why use font size in points? As other elements, like widgets,
> images, etc has size in pixels, it's better to use pixels for fonts
> too. Auto HiDPI scaling in Qt works for font sizes in pixels.

My point is that we already have such a unit. Instead of inventing a new one 
that didn't exist before, then use it in a context where a unit was already 
proper, why not use the proper unit for everything? Measure images in points 
too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Nikita Krupenko]

2016-07-27 4:02 GMT+03:00 Thiago Macieira :
> Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko
> escreveu:
>> In Material Design guidelines [1] all font sizes are in scaleable
>> pixels (sp). So this size could be multiplied by some factor and all
>> fonts should scale equally.
>
> Maybe we should instead use a size calculated in physical units, like 1/72th
> of an inch. Oh, we have such a unit: points.

The idea of scaleable pixels is somewhat different: user can select
big/small fonts in the OS/application settings and font sizes would be
multiplied by some factor, for example 1.5.

BTW, why use font size in points? As other elements, like widgets,
images, etc has size in pixels, it's better to use pixels for fonts
too. Auto HiDPI scaling in Qt works for font sizes in pixels.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Thiago Macieira]

Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko 
escreveu:
> In Material Design guidelines [1] all font sizes are in scaleable
> pixels (sp). So this size could be multiplied by some factor and all
> fonts should scale equally.

Maybe we should instead use a size calculated in physical units, like 1/72th 
of an inch. Oh, we have such a unit: points.

> I think, it's worth to add the support of the font scale factor to the
> Qt (enabled by something like Qt::AA_EnableFontScaling). And platform
> plugin could try to get font scale factor from the OS settings and use
> it by default.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Nikita Krupenko]

2016-07-19 15:58 GMT+03:00 Shawn Rutledge :
>> App should remember of couse this setting to restore it back at restart
>
> How should Qt encourage this?  So far we have QSettings, but you need to 
> define your own setting.  And we have not made it easy to scale all fonts 
> simultaneously, interactively.  Bindings are too cumbersome and expensive to 
> be the universal solution.  To avoid setting the font on every individual 
> Text item in a QtQuick app, for example, you can use 
> QGuiApplication::setFont().  But that’s just for the default.  Maybe there 
> should be an event of some sort when you do that at runtime, which every Text 
> will react to, and which will then trigger the necessary layout changes.  But 
> that would only take care of Text which uses the default font, so we need 
> that unit support in QML (which has been discussed for years but not done 
> yet) to be able to have a unit which represents the default font size, so 
> that larger text could have a size 1.2x as big as the default instead of an 
> actual point size.  Or maybe the event should be sent when you do 
> QHighDpiScaling::setScreenFactor(), but that’s private API so far, and it’s 
> still not clear to me which of those Qt high dpi-things are intended to 
> affect only or mainly font sizes, and which of them demand everything to be 
> scaled even if it will cause crappy results (scaling up pixmaps or 
> pre-rendered widgets by non-integral ratios).  The prototype zoom-slider is 
> in qtbase/tests/manual/highdpi, but you can see what goes wrong with that.  
> We need a similar test for QtQuick to see what goes wrong with dynamic 
> scaling there.

In Material Design guidelines [1] all font sizes are in scaleable
pixels (sp). So this size could be multiplied by some factor and all
fonts should scale equally.

I think, it's worth to add the support of the font scale factor to the
Qt (enabled by something like Qt::AA_EnableFontScaling). And platform
plugin could try to get font scale factor from the OS settings and use
it by default.

[1] 
https://material.google.com/layout/units-measurements.html#units-measurements-scaleable-pixels-sp-
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Stephen Chu]

On 7/20/16, 5:12 AM, "Development on behalf of Edward Welbourne" 
 wrote:

>
>Then again, our SVG support is embarrassingly poor,

Especially when it doesn’t support clip path. Which I imagine will be vital for 
icon designs.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Prav]

Hello, Everyone and Thiago.

>> SVG icons are not shown at all in static builds of Qt, but png icons are
>> fine (both icons are taken from resorse file). Static and shred Qt 5.6.1
>> build were done with same config settings except of cause "static".

> Remember to force the inclusion of the svg icon plugin into your application.

This seems a valuable advise which worked for me. I finally found how to do 
this, In pro-file add:
QTPLUGIN *= qsvg


Without this svg icons just do not render SILENTLY (in "static").

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Uwe Rathmann]

On Wed, 20 Jul 2016 10:44:16 -0700, Thiago Macieira wrote:

>> Why SVG support of QIcon can not cache rendered result? So re-rendering
>> will be as fast as for PNGs. Or you are saying about app startup time?
> 
> Startup.

When using SVGs you have to load/parse it into QSvgRenderer and later it 
needs to be replayed via QPainter in the size you need.

While the second step can't be avoided at runtime, it is possible to 
convert SVGs into something, that can be loaded significantly faster, at 
compile time.

I'm using an implementation based on this class: http://
qwt.sourceforge.net/class_qwt_graphic.html. This is a record/replay 
device for QPainter commands - like QPicture, but suitable for vector 
graphics. I added load/save methods ( not yet in SVN ) and then the 
compiler itself is 20 lines of code only.

When using such a concept with Qt Quick, better don't use standard Image 
classes as they are designed for raster graphics. Better write your own 
type of control for it - at least this is what I did.

Uwe


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Konstantin Tokarev]

20.07.2016, 21:08, "Thiago Macieira" :
> On quarta-feira, 20 de julho de 2016 21:03:48 PDT Prav wrote:
>>  > Startup.
>>
>>  Approximately how many icons app have to have to see influence on app's
>>  startup?
>
> That depends on the complexity of your SVG icons and how powerful your CPU is.
>
>>  > I can't speak for business decisions. But however faster that engine is,
>>  > it'll still be orders of magnitude slower than PNG.
>>
>>  But scaling is a problem.
>
> Yes. It's a trade-off.

One could use SVG to C++ translator to trade CPU usage / startup time to code 
size (and probably feature set)

http://zrusin.blogspot.ru/2006/07/compiling-svg-to-c.html

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Thiago Macieira]

On quarta-feira, 20 de julho de 2016 21:03:48 PDT Prav wrote:
> > Startup.
> 
> Approximately how many icons app have to have to see influence on app's
> startup?

That depends on the complexity of your SVG icons and how powerful your CPU is.

> > I can't speak for business decisions. But however faster that engine is,
> > it'll still be orders of magnitude slower than PNG.
> 
> But scaling is a problem.

Yes. It's a trade-off.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Prav]

> Startup.

Approximately how many icons app have to have to see influence on app's startup?


>> Also there was idea in this thread earlier that SVG rendering can be done
>> much faster ... like in old Opera browser. Why Qt company cann't ask Opera
>> to share this part of old Presto engine? They decided to not use Presto
>> nowdays so no loses for them.

> I can't speak for business decisions. But however faster that engine is, it'll
> still be orders of magnitude slower than PNG.

But scaling is a problem.


>> But for people who really want raster images to be aplied ... may be it is
>> possible to add some method to QIcon which will store this specially
>> rastered QPixmap in icon and will render icon with this pixmap if icon size
>> is small. But I am sure most apps will be happy with just SVG rendering.
>> This is such a detailed work ... not sure that many apps creators will
>> decide this work as a high priority.

> As Morten said, Qt does not have a choice: we have to support both SVG and
> raster icons.

Agree. I am about details. If user can only select SVG OR PNG this is one way 
to support both icon formats.

I was trying to say that combined variant is imaginable and is interesting 
because can have benefits of both formats.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Konstantin Tokarev]

20.07.2016, 20:12, "Prav" :
> Hello, Everyone.
>
>>  That's one reason, but there are two more equally, if not more important:
>>  1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy
>>  applications suffer if they use it.
>
> Why SVG support of QIcon can not cache rendered result? So re-rendering will 
> be as fast as for PNGs.
> Or you are saying about app startup time?
>
> Also there was idea in this thread earlier that SVG rendering can be done 
> much faster ... like in old Opera browser.
> Why Qt company cann't ask Opera to share this part of old Presto engine? They 
> decided to not use Presto
> nowdays so no loses for them.

Is SVG engine of Opera really faster than that of WebKit?

>
>>  2) SVG icons designed for higher resolution, with a lot of details, look
>>  complex and polluted in lower resolutions. From past experience, icon 
>> artists
>>  prefer to render the SVG to a lower resolution and retouch them.
>
> This is a problem. But I do not see many such icons in Material-style. They 
> are mostly simple.
> So I would expect modern styled-apps will not have this problem massively.
>
> But for people who really want raster images to be aplied ... may be it is 
> possible to add some method
> to QIcon which will store this specially rastered QPixmap in icon and will 
> render icon with this
> pixmap if icon size is small. But I am sure most apps will be happy with just 
> SVG rendering.
> This is such a detailed work ... not sure that many apps creators will decide 
> this work as a high priority.
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Prav]

Hello, Everyone.

> That's one reason, but there are two more equally, if not more important:
> 1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy
> applications suffer if they use it.
Why SVG support of QIcon can not cache rendered result? So re-rendering will be 
as fast as for PNGs.
Or you are saying about app startup time?

Also there was idea in this thread earlier that SVG rendering can be done much 
faster ... like in old Opera browser.
Why Qt company cann't ask Opera to share this part of old Presto engine? They 
decided to not use Presto
nowdays so no loses for them.


> 2) SVG icons designed for higher resolution, with a lot of details, look
> complex and polluted in lower resolutions. From past experience, icon artists
> prefer to render the SVG to a lower resolution and retouch them.
This is a problem. But I do not see many such icons in Material-style. They are 
mostly simple.
So I would expect modern styled-apps will not have this problem massively.

But for people who really want raster images to be aplied ... may be it is 
possible to add some method
to QIcon which will store this specially rastered QPixmap in icon and will 
render icon with this
pixmap if icon size is small. But I am sure most apps will be happy with just 
SVG rendering.
This is such a detailed work ... not sure that many apps creators will decide 
this work as a high priority.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Thiago Macieira]

On quarta-feira, 20 de julho de 2016 13:03:03 PDT Prav wrote:
> SVG icons are not shown at all in static builds of Qt, but png icons are
> fine (both icons are taken from resorse file). Static and shred Qt 5.6.1
> build were done with same config settings except of cause "static".

Remember to force the inclusion of the svg icon plugin into your application.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Thiago Macieira]

On quarta-feira, 20 de julho de 2016 09:12:53 PDT Edward Welbourne wrote:
> I am baffled that anyone does the _x2, etc., approach to icons any more,
> when most icons are indeed well-suited to SVG - in most cases, a tiny
> SVG, smaller (in file-size) than any one of the many icons it makes
> redundant, can do an excellent job of presenting the clear visual that
> the icon is supposed to provide.  Making many larger files seems to
> serve no purpose - other than letting web-or-UI designers bill their
> clients for large amounts of pointless make-work.
> 
> Then again, our SVG support is embarrassingly poor,

That's one reason, but there are two more equally, if not more important:

1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy 
applications suffer if they use it.

2) SVG icons designed for higher resolution, with a lot of details, look 
complex and polluted in lower resolutions. From past experience, icon artists 
prefer to render the SVG to a lower resolution and retouch them.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 20 Jul 2016, at 14:51, André Somers  wrote:
> 
> 
> 
> Op 20/07/2016 om 14:23 schreef Morten Sorvig:
>>> On 19 Jul 2016, at 14:58, Shawn Rutledge  wrote:
>>> 
>>> 
>>> I agree that most apps should have a means of scaling.  Control-mousewheel 
>>> and control+/- are common on the desktop, so maybe it ought to be 
>>> universal.  So far we have browsers, image and drawing viewers and editors, 
>>> text editors (like Creator’s) and terminals which have the feature, but 
>>> many other applications don’t.
>> This would be a "document scaling” feature. Notice that the application UI
>> does not scale when using and control+/-. So this is orthogonal to the
>> current high-DPI support and can’t reuse that implementation.
>> 
>> 
> Not really. In the browser, the web content often is the real application the 
> user interacts with.
> 

I think this is a special case that does not invalidate the general point. The
browser UI still does not scale. But I agree, if you have application UI 
elements
in your document those should scale too.

Morten
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 20 Jul 2016, at 14:52, Edward Welbourne  wrote:
> 
> Morten Sorvig said:
>> I’d like us to support both, were an icon/image with more pixels can
>> be designated as either “larger” (more content) or “higher resolution”
>> (more detail).
> 
> which is why SVG has to be the way to go - so you just specify the
> different levels of detail and let size be a display-time choice - else
> you'll end up with a quadratic explosion of different images,
> parameterised by detail-ness and by size.

Yes, as an application developer I will seriously consider using SVGs only. As
library developers we should support both approaches.

Morten



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Edward Welbourne]

Morten Sorvig said:
> I’d like us to support both, were an icon/image with more pixels can
> be designated as either “larger” (more content) or “higher resolution”
> (more detail).

which is why SVG has to be the way to go - so you just specify the
different levels of detail and let size be a display-time choice - else
you'll end up with a quadratic explosion of different images,
parameterised by detail-ness and by size.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 20 Jul 2016, at 12:47, Edward Welbourne  wrote:
> 
> Michael Zanetti
> 
>> Well, in smaller icons you can have less details than in bigger icons,
>> so having multiple icons does make sense.
> 
> That's fair enough - but the thing that makes sense is having more and
> less detailed icons, not bigger and smaller ones.  Of course, you'll
> want to use the more detailed one for bigger uses and the less detailed
> for smaller uses, but each should cover a wide range of sizes cleanly.
> 

I’d like us to support both, were an icon/image with more pixels can be
designated as either “larger” (more content) or “higher resolution”
(more detail).

Morten

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Edward Welbourne]

Michael Zanetti

> Well, in smaller icons you can have less details than in bigger icons,
> so having multiple icons does make sense.

That's fair enough - but the thing that makes sense is having more and
less detailed icons, not bigger and smaller ones.  Of course, you'll
want to use the more detailed one for bigger uses and the less detailed
for smaller uses, but each should cover a wide range of sizes cleanly.

> Also rendering svg icons is
> slower than bitmaps so in some cases that won't work out either.

That means the SVG renderer isn't good enough.  I really wish we could
get hold of the team that implemented Opera's SVG engine in Presto - now
discarded in favour of Chrome - to do the job well: they wrote a good
engine that worked fast.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Prav]

Heello, Everyone!

> Then again, our SVG support is embarrassingly poor,
Exactly!
For example if you set SVG icon for button and then scale the app with 
something like QT_SCALE_FACTOR=2 before running the app ... icon will be 
bluered like this is not SVG!
With QT_SCALE_FACTOR=1 icon looks fine.
But fonts looks sharp for both QT_SCALE_FACTOR=1 and =2. Strange?
(Qt 5.6.1, Windows).

SVG icons are not shown at all in static builds of Qt, but png icons are fine 
(both icons are taken from resorse file). Static and shred Qt 5.6.1 build were 
done with same config settings except of cause "static".
Strange too.
(Qt 5.6.1, Windows).

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Michael Zanetti]

On 20.07.2016 11:12, Edward Welbourne wrote:
> Prav said:
>> Another problem will be with icons. They will scale bad. We are used
>> to make icons with versions like _x2, _x3 ... and what we going to do
>> if scale factor will be fractional? ... have icons versions like _1.1
>> _1.2 _1.3?  Probably we need to rethink why in the world we make so
>> many copies of one icon in compile time if we can make one SVG icon
>> which can be scaled to any size without loss of crispness in
>> runtime. Especially material design makes this easier because we
>> mostly see only contours in material design icons.  So the next step
>> for Qt can be supporting of SVG-icons as main and preferable way for
>> setting icons. In this case icons can be scaled clearly.
> 
> I am baffled that anyone does the _x2, etc., approach to icons any more,
> when most icons are indeed well-suited to SVG - in most cases, a tiny
> SVG, smaller (in file-size) than any one of the many icons it makes
> redundant, can do an excellent job of presenting the clear visual that
> the icon is supposed to provide.  Making many larger files seems to
> serve no purpose - other than letting web-or-UI designers bill their
> clients for large amounts of pointless make-work.

Well, in smaller icons you can have less details than in bigger icons,
so having multiple icons does make sense. Also rendering svg icons is
slower than bitmaps so in some cases that won't work out either.

What we do in ubuntu is to find the closes available icon that's larger
than the current ui scale and then scale it down. In case no larger one
is available we fall back to the closest available smaller one and scale
it up. And as I said before, we also use icon_x2.svg and icon_x3.svg for
different levels of details in the image.


> 
> Then again, our SVG support is embarrassingly poor,
> 
> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 



signature.asc
Description: OpenPGP digital signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Prav]

Hello, Everyone!

> Or, come up with another gesture for that kind of zooming.
> The devil’s in the details, and we’ve had a proliferation of details over the 
> last few years.
> ... and many other thoughts

I wanted to say that right DPI for screen should give only default scale factor 
for the app. And app should be able to change the scale
factor easy at runtime and with fractional values so that user can unjust the 
scale factor according to himself and his current environment.

So here I confirm that I see that "HighDPI" and "scaling factor" should be 
solved with the same technology. BUT ... we need screen's DPI only as a 
starting guess for setting the scale factor.
Later we need to let user adjust it.

I think that Qt lib should not go deeper in this by now ... like forcing some 
standard way to do scaling for the app. With common gesture or std shortcut.
And this is simply because we are not sure what the best way is. I think what 
Qt have to make app scaling as easy
as calling of one function and advertise on every corner that apps have to use 
this function and let user change scale factor if app wants to be considered 
"modern" and "good".

After that users and apps will create the best practice in this area and then 
Qt can implement it. Currently it is too early.


I am not sure that this "setScaleFactor" function is currently implemented.
For example here
http://blog.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6/
I see only use of environment variable before start of the app for manual 
setting of scale factor.
But why I can not change it in runtime is still unclear for me.


I agree that changing of scale factor means that size of window will be 
changed. And what if this cannot be done more ... end of screen size ... what 
to do?
Well we have layouts for this. But here is the problem ... Qt layouts have not 
been changed/extended for so long that in current new conditions
devs would probably think that they are not happy with standard Qt layouts and 
would like to extend them (for example Horizontal layout
can not ever layout things vertically ... even if there is no space in 
horizontal direction and plenty in vertical).
But here is the problem ... we have mechanism to extend widgets (Promotion) but
this mechanism somehow is absent for layouts! Why?!
I am not sure about QML layouts problems ... probably anchors make it easier to 
define custom layouting in QML (but still not sure that everything is without 
problems in QML)
but with widgets ... I never saw news about adding or extending any 
widget-layout.
But this is in need after setScaleFactor will be implemented! ... because you 
can scroll the page vertically
but horizontal scrolling is a bad tone ... so there is need in some std layout 
which will use vertical direction if the layout is out of horizontal space and
there devs need possibility to extend layouts something like we have for 
widgets.


Another problem will be with icons. They will scale bad. We are used to make 
icons with versions like _x2, _x3 ... and what we going to do if scale factor
will be fractional? ... have icons versions like _1.1 _1.2 _1.3?
Probably we need to rethink why in the world we make so many copies of one icon 
in compile time if we can make one SVG icon which can be scaled
to any size without loss of crispness in runtime. Especially material design 
makes this easier because we mostly see only contours in material design icons.
So the next step for Qt can be supporting of SVG-icons as main and preferable 
way for setting icons. In this case icons can be scaled clearly.


I mean that this scaling-problem have to be discussed more in this terms ... in 
terms of support of already known technologies which by now were
not developed enough to make fractional runtime scaling easy ... but not only 
in terms of getting right DPI. Right DPI-factor is not close to the problem 
solution ... at ALL!

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 19 Jul 2016, at 10:57, Prav  wrote:
> 
> May be Qt need to move accents from getting right DPI to making it user 
> changeable ... FRACTIONALLY (as a good new practice)!
> Like 10-20 % steps ... not just 2,3,4,5.
> 
> I do not see much trend in Qt-discussions/apps-interfaces about user-defined 
> scale factor. But only THIS is important to user.
> And NOT DPI ;)


I would like to separate the use cases of adapting to hardware with
different DPI and adapting to user preferences. We can support both
and they don’t have to be mutually exclusive. They may share 
implementation details.

Is user control an OS setting or an application setting? Many
windowing systems have global font preferences which Qt should respect.

If we want to re-use the existing high-DPI work we can add

QGuiApplication::setGlobalScaleFactor(qreal factor);

Setting the factor to something other than 1 would uniformly scale all
application windows. This would interact with the current high-DPI support:
a factor of 1.5 on a 2x display gives an effective devicePixelRatio of 3,
ensuing a consistent visual UI size.

Morten

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Shawn Rutledge]

> On 19 Jul 2016, at 10:57, Prav  wrote:
> 
> Hello, Everyone!
> 
>> The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to
>> focus on two aspects:
>>1) Automatic scale factor configuration based on system settings.
> There so many debates about this topic and how to get real DPI for all 
> devices correctly.
> But I personally does get this as SO important thing. And this is because 
> people are different
> and have different preferences about reading from screen (because of eyes or 
> just personally).
> Which brings me to understanding that it does not matter what is the DPI of 
> screen. It matter only
> how large PERSON want program font normally be.
> So I would expect that the main intention in developing of apps should be 
> moved toward giving
> the user possibility to scale the app.
> And you are done!

I agree that most apps should have a means of scaling.  Control-mousewheel and 
control+/- are common on the desktop, so maybe it ought to be universal.  So 
far we have browsers, image and drawing viewers and editors, text editors (like 
Creator’s) and terminals which have the feature, but many other applications 
don’t.  I got a 4K display at work, so now I want to use konsole instead of 
urxvt, because of this feature: I need to zoom it depending on the use case, 
and which screen it’s on.  (On the Mac though, I wouldn’t need it so urgently.  
The window has a similar physical size as I move it from one screen to another; 
whereas on Linux, the non-highdpi-aware window manager will keep the same pixel 
dimensions as I move it across.  So it’s a much smaller window on the 4K 
screen, regardless whether the content inside gets scaled or not.  Is that 
right or wrong?  Are we waiting for window managers to catch up here?  I don’t 
think resizing the window is necessarily Qt’s problem, although sometimes the 
layout does drive the minimum window size.)  I don’t use Qt’s auto-scaling, 
because in general I want smaller fonts on the 4K display, but I want to be 
able to choose the scale, and fractional scaling works so badly now.  Widget 
styles seem to need some re-design to be scalable.

But there should also be a system-wide setting for font sizes, and it should be 
respected by default.  Unfortunately the settings like this in most OSes are 
kindof coarse.  With distance field rendering, font scaling can be completely 
continuous, but that’s only in QtQuick apps.

The most common problem with zooming will be the need to use good layout 
management in the application.  Apps should do that anyway, if they want any 
portability at all.  But there will be threshold problems: if the 
screen/font-size ratio doesn’t allow enough space, you want to switch from a 
layout which uses too much horizontal space to a completely different one that 
doesn't.

There are also cases when accurate calibration is important though.  Some 
people are actually still engaged in preparing print media, for example.  They 
will appreciate having 100% zoom result in the same scale as it will be on 
paper.  And such people should either buy monitors which have correct EDID, or 
know how to correct it in their OSes.

> App should remember of couse this setting to restore it back at restart

How should Qt encourage this?  So far we have QSettings, but you need to define 
your own setting.  And we have not made it easy to scale all fonts 
simultaneously, interactively.  Bindings are too cumbersome and expensive to be 
the universal solution.  To avoid setting the font on every individual Text 
item in a QtQuick app, for example, you can use QGuiApplication::setFont().  
But that’s just for the default.  Maybe there should be an event of some sort 
when you do that at runtime, which every Text will react to, and which will 
then trigger the necessary layout changes.  But that would only take care of 
Text which uses the default font, so we need that unit support in QML (which 
has been discussed for years but not done yet) to be able to have a unit which 
represents the default font size, so that larger text could have a size 1.2x as 
big as the default instead of an actual point size.  Or maybe the event should 
be sent when you do QHighDpiScaling::setScreenFactor(), but that’s private API 
so far, and it’s still not clear to me which of those Qt high dpi-things are 
intended to affect only or mainly font sizes, and which of them demand 
everything to be scaled even if it will cause crappy results (scaling up 
pixmaps or pre-rendered widgets by non-integral ratios).  The prototype 
zoom-slider is in qtbase/tests/manual/highdpi, but you can see what goes wrong 
with that.  We need a similar test for QtQuick to see what goes wrong with 
dynamic scaling there.

Maybe we should have an optional feature in QQmlApplicationEngine (just set one 
flag or property, plus setOrganizationName and setApplicationName), or in a 
subclass, which makes it easy to make an application zoomable (even 

Re: [Development] Revisiting high-DPI configuration options

[Samuel Stirtzel via Development]

2016-07-19 12:48 GMT+02:00 Ulf Hermann :
>
>> I'm still entirely sure that "let the user decide" was a better way to
>> settle how big the page should be, what fonts and colour-schemes to use;
>> by all means let the author give hints and suggestions to the
>> presentation system, but let the user have the final say.  I shall like
>> the look of your document better if it's in a font I've chosen because I
>> find it easier or nicer to read; I shall like the appearance of your
>> page better if the overall colour scheme fits in with my desktop
>> environment; I shall like your web-site better if it adapts itself to my
>> tastes - and letting it do so spares you the need to agonise over which
>> entirely subjective details appeal to a bigger audience.
>
>
> I totally agree with this as long as we're talking about documents - mostly
> consisting of text, to be read top to bottom (or some other direction,
> depending on locale). It gets hairy if we're talking about graphical
> applications where text only plays a minor role, and most of the visual
> elements have size constraints. It's very hard to have all those visual
> elements and their interactions scale smoothly to any dimensions or color
> schemes the user may choose. So, for those applications the designer usually
> chooses a few predefined UI styles, and tries to prevent the user from
> messing with those, as the result of that messing would only look bad and
> glitchy.
>

No offense, but that sounds very biased towards a designers standpoint.
Applications like the Winamp media player for example have shown that
user designed styles can very well benefit software that is not even
close to a document viewer.
Even if some user created style would look bad (based on opinions),
how would anyone blame the application for being customizable?

>From a technical standpoint it may not be trivial to develop a scaling
user interface, but OTOH the gained usability may be worth it (also it
saves the developers from the DPI hassle).
The topic may be as well compared to HTML, where the users can scale
the user interface and have utilities at hands that are capable of
changing the appearance of every website to their personal flavor.



-- 
Regards
Samuel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Ulf Hermann]

I'm still entirely sure that "let the user decide" was a better way to
settle how big the page should be, what fonts and colour-schemes to use;
by all means let the author give hints and suggestions to the
presentation system, but let the user have the final say.  I shall like
the look of your document better if it's in a font I've chosen because I
find it easier or nicer to read; I shall like the appearance of your
page better if the overall colour scheme fits in with my desktop
environment; I shall like your web-site better if it adapts itself to my
tastes - and letting it do so spares you the need to agonise over which
entirely subjective details appeal to a bigger audience.


I totally agree with this as long as we're talking about documents - mostly 
consisting of text, to be read top to bottom (or some other direction, 
depending on locale). It gets hairy if we're talking about graphical 
applications where text only plays a minor role, and most of the visual 
elements have size constraints. It's very hard to have all those visual 
elements and their interactions scale smoothly to any dimensions or color 
schemes the user may choose. So, for those applications the designer usually 
chooses a few predefined UI styles, and tries to prevent the user from messing 
with those, as the result of that messing would only look bad and glitchy.

Ulf
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Edward Welbourne]

On Tuesday 19 July 2016 11:57:20 Prav wrote:
>> it does not matter what is the DPI of screen. It matter only how
>> large PERSON want program font normally be.  So I would expect that
>> the main intention in developing of apps should be moved toward
>> giving the user possibility to scale the app.
[snip]
>> I do not see much trend in Qt-discussions/apps-interfaces about
>> user-defined scale factor. But only THIS is important to user. And
>> NOT DPI ;)

The situation with app-UIs reminds me of that with web-pages.

Back in 1994, when I first met the web, one of the things that delighted
me about it was that the user was in control of how things were
displayed; the author's mark-up said the general necessities
(paragraphs, headings, etc.) and left it to the user agent and user to
find a way of displaying the content that the user found it convenient
and easy to read.

This flew in the face of graphic design orthodoxy, where the author must
control every particular of the user's experience - the size of the
page, the fonts and colours used, the margins and layout.  In time, the
graphic designers got their way and now they are able to impose their
choices on users.  So their lamentation is great when the can't take all
control away from the user.

I'm still entirely sure that "let the user decide" was a better way to
settle how big the page should be, what fonts and colour-schemes to use;
by all means let the author give hints and suggestions to the
presentation system, but let the user have the final say.  I shall like
the look of your document better if it's in a font I've chosen because I
find it easier or nicer to read; I shall like the appearance of your
page better if the overall colour scheme fits in with my desktop
environment; I shall like your web-site better if it adapts itself to my
tastes - and letting it do so spares you the need to agonise over which
entirely subjective details appeal to a bigger audience.

It used to be easy on the web; now it has become difficult, because the
emphasis has all been on giving the author control, not the user.  Let
us try to give app-UI designers the chance to go in the opposite
direction.

Frank Hemer replied:
> Precisely my experience
> +1

Likewise,
+1

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Frank Hemer]

On Tuesday 19 July 2016 11:57:20 Prav wrote:
> Hello, Everyone!
> 
> > The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to
> > 
> > focus on two aspects:
> > 1) Automatic scale factor configuration based on system settings.
> 
> There so many debates about this topic and how to get real DPI for all
> devices correctly. But I personally does get this as SO important thing.
> And this is because people are different and have different preferences
> about reading from screen (because of eyes or just personally). Which
> brings me to understanding that it does not matter what is the DPI of
> screen. It matter only how large PERSON want program font normally be.
> So I would expect that the main intention in developing of apps should be
> moved toward giving the user possibility to scale the app.
> And you are done!
> 
> All this problems in getting correct DPI of screen would NOT be so painfull.
> Your phone or monitor or OS or something resulted in incorrect scale
> factor? ... does not matter! ... increase/decrease scale factor for that
> app as you like ... and here you are ... having this app comfortable for
> eyes and personal preferences (not for DPI of scrrent ... most people even
> do not know what it is and why they should care)! App should remember of
> couse this setting to restore it back at restart
> > 2) Handling fractional scale factors (rounding).
> 
> Previous idea need fractional scale factors to work ... FOR SURE!
> 
> 
> 
> PS I can give many more cases then getting right DPI does not give usability
> to user. 1. Developers or Designers are young, have good eyes are pretty
> conformable with small fonts. They produce app with HighDPI support which
> correctly scales to DPI of HighDPI user device. But ... this does not mean
> that old persons would feel comfortable with the app ... their eyes see not
> as good as when they were young. 2. Could be a reverse case ... like you
> want smaller because devs created app which seems larger to you. 3. Devs
> and Designers usually have good tech. I mean good monitors, modern phones
> with good crisp screen. But user's tablet/phone can be not modern or be
> cheap or with tons of scratches (for example with plastic (not glass
> screens)). Sooo ... visibility is much worse ... but DPI could be same.
> 4. You are OK with design and size of app's fonts at your notebook/tablet
> with like 10'', devs and designer see things the same good as you and your
> screen is modern and good with gorilla glass or something same and DPI
> scale factor was determined exactly as it is. But now you are inside city
> transport ... and guess what ...
> you are shaken! ... and this mean you see the screen worse ... you need
> to increase the scale! And if you sit/lay still in the bedroom you what
> smaller font to see more info at once.
> 
> I have nothing against getting right DPI at app's startup ...
> 
> I wanted just to say that I see that it is actually NOT THE MAIN PURPOSE!
> ... for usability!
> 
> May be Qt need to move accents from getting right DPI to making it user
> changeable ... FRACTIONALLY (as a good new practice)! Like 10-20 % steps
> ... not just 2,3,4,5.
> 
> I do not see much trend in Qt-discussions/apps-interfaces about user-defined
> scale factor. But only THIS is important to user. And NOT DPI ;)

Precisely my experience
+1

Frank
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Prav]

Hello, Everyone!

> The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to
> focus on two aspects:
> 1) Automatic scale factor configuration based on system settings.
There so many debates about this topic and how to get real DPI for all devices 
correctly.
But I personally does get this as SO important thing. And this is because 
people are different
and have different preferences about reading from screen (because of eyes or 
just personally).
Which brings me to understanding that it does not matter what is the DPI of 
screen. It matter only
how large PERSON want program font normally be.
So I would expect that the main intention in developing of apps should be moved 
toward giving
the user possibility to scale the app.
And you are done!

All this problems in getting correct DPI of screen would NOT be so painfull. 
Your phone or monitor or OS or something
resulted in incorrect scale factor? ... does not matter! ... increase/decrease 
scale factor for that app as you like ... and here you are ... having this app
comfortable for eyes and personal preferences (not for DPI of scrrent ... most 
people even do not know what it is and why they should care)!
App should remember of couse this setting to restore it back at restart

> 2) Handling fractional scale factors (rounding).
Previous idea need fractional scale factors to work ... FOR SURE!



PS I can give many more cases then getting right DPI does not give usability to 
user.
1. Developers or Designers are young, have good eyes are pretty conformable 
with small fonts.
They produce app with HighDPI support which correctly scales to DPI of 
HighDPI user device. But ... this does not mean
that old persons would feel comfortable with the app ... their eyes see not 
as good as when they were young.
2. Could be a reverse case ... like you want smaller because devs created app 
which seems larger to you.
3. Devs and Designers usually have good tech. I mean good monitors, modern 
phones with good crisp screen.
But user's tablet/phone can be not modern or be cheap or with tons of 
scratches (for example with plastic (not glass screens)).
Sooo ... visibility is much worse ... but DPI could be same.
4. You are OK with design and size of app's fonts at your notebook/tablet with 
like 10'', devs and designer see things the same good as you
and your screen is modern and good with gorilla glass or something same and 
DPI scale factor was determined exactly as it is.
But now you are inside city transport ... and guess what ...
you are shaken! ... and this mean you see the screen worse ... you need to 
increase the scale!
And if you sit/lay still in the bedroom you what smaller font to see more 
info at once.

I have nothing against getting right DPI at app's startup ...

I wanted just to say that I see that it is actually NOT THE MAIN PURPOSE! ... 
for usability!

May be Qt need to move accents from getting right DPI to making it user 
changeable ... FRACTIONALLY (as a good new practice)!
Like 10-20 % steps ... not just 2,3,4,5.

I do not see much trend in Qt-discussions/apps-interfaces about user-defined 
scale factor. But only THIS is important to user.
And NOT DPI ;)

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 22 Jun 2016, at 15:30, Michael Zanetti  
> wrote:
> 
> 
> * 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.
> 

This may be in reach for a future version of Qt.

* Floating point scaling has already been discussed. Qt uses qreal to store
  and access the scale factor so support is mostly limited by rendering and
  style code.

* The main scale factor accessor is QWindow::devicePixelRatio(), which 
dynamically
  update on screen changes. There are currently some code paths that have to use
  QScreen::devicePixelRatio() or even QGuiApplication::devicePixelRatio(), but I
  would like us to gravitate towards the QWindow accessor as much as possible.

  (QWindow::devicePixelRatio() has aliases such as 
QPaintDevice::devicePixelRatioF()
   and QQuickWindow::effectiveDevicePixelRatio() higher up in the stack.)

  There are two approaches to detect devicePixelRatio changes: either a spesific
  dprChanged event, or use expose events where rendering code queries 
devicePixelRatio().
  
  We did have support for _setting_ a per-window scale factor from application
  code at one point during development, but it was removed since we were not 
sure
  we could make it work in all cases. (I don’t remember the exact reasoning)

* Grid units for QML: looks interesting, but I can’t really comment on the
  feasibility of implementing it in Qt. 

Morten


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 22 Jun 2016, at 15:32, ekke  wrote:
> 
> Am 22.06.16 um 14:46 schrieb Morten Sorvig:
>>> 
>> 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.
>> 
> my android device  reports 3.5 for
> 
> qApp->primaryScreen()->devicePixelRatio()
> 
> Does this mean Qt is using 4.0 and not 3.5 as scale factor ?
> Images are correctly used from @4

In this case Qt is indeed using 3.5. And when loading images we round up
and use the @4 version. You could double check that this actually the value
DisplayMetrics.density() returns, but I think we’ll find that it is.

This data point suggests that the Android world is not as simple as
the above table.

Morten

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[ekke]

Am 22.06.16 um 14:46 schrieb Morten Sorvig:
>> On 22 Jun 2016, at 10:30, Michael Zanetti  
>> 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.
my android device  reports 3.5 for

qApp->primaryScreen()->devicePixelRatio()


Does this mean Qt is using 4.0 and not 3.5 as scale factor ?
Images are correctly used from @4

ekke
> 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.
>
> Morten
>
> http://stackoverflow.com/questions/3166501/getting-the-screen-density-programmatically-in-android
> https://groups.google.com/forum/#!msg/android-developers/g56jV0Hora0/9d8p8QJg1ksJ
>

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Michael Zanetti]

On 22.06.2016 14:46, Morten Sorvig wrote:
> 
>> On 22 Jun 2016, at 10:30, Michael Zanetti  
>> 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

Re: [Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 22 Jun 2016, at 10:30, Michael Zanetti  
> 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.

Morten

http://stackoverflow.com/questions/3166501/getting-the-screen-density-programmatically-in-android
https://groups.google.com/forum/#!msg/android-developers/g56jV0Hora0/9d8p8QJg1ksJ


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 21 Jun 2016, at 15:24, Samuel Stirtzel via Development 
>  wrote:
> 
> 2016-06-21 14:15 GMT+02:00 Shawn Rutledge :
>> 
>>> On 20 Jun 2016, at 18:09, Thiago Macieira  wrote:
>>> 160x90 mm is a valid screen size, correspoding to a 7.2" monitor.
>> 
>> Of course, it’s just suspicious (being a fallback value, apparently), but 
>> not impossible.
> 
> Unfortunately it's not a fallback value, instead TV manufacturers
> commonly only set the aspect ratio (in cm) because one EDID for all
> devices is cheaper.
> See bullet point d of Adam Jacksons mail about the EDID -> DPI topic:
> https://lists.fedoraproject.org/pipermail/devel/2011-October/157671.html
> 

I would also like to add that even if you _do_ get a trustable screen size,
using physical DPI as a general purpose solution has flaws:

* Physical sizes do not account for viewing distance, logical DPI/scale
  usually do. For example, a 2x iPhone has a higher pixel density than
  a 2x MacBook. The base Android DPI is 160.

* You actually want some amount of quantization, at least for the general
  desktop use case. I use two 1x class screens with slightly different
  physical DPI. What happens when you move a window from one screen to
  another? If content size is based on physical DPI you get a shift in
  content logical size, and possibly a resize of the window, which is
  unexpected. Similarly windows scaling happens in 25% increments.

Physical DPI is fine as a special purpose solution where the user or developer
is in complete control of the hardware. For Qt I think this translates to that 
we can support using physical DPI, but it can’t be the default. 

Morten





___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Shawn Rutledge]

> On 22 Jun 2016, at 10:21, Morten Sorvig  wrote:
> 
> 
>> On 22 Jun 2016, at 09:17, Shawn Rutledge  wrote:
>> 
>> 
>>> On 21 Jun 2016, at 21:26, Thiago Macieira  wrote:
>>> 
>>> On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote:
 I think using screen names can be a good match for cases where you are
 sometimes connecting to external screens, provided that the string returned
 by name() is unique for each screen.
>>> 
>>> It's not. It's always "DP-1" (it reports the connection, not the monitor).
>> 
>> So far that’s a difference between OS X (which reports the monitor’s model 
>> name) and Linux (which reports the output name).  If we could get both, on 
>> all OSes (which I’m not sure of), maybe we could format it like “SyncMaster 
>> on HDMI-1” or some such.
> 
> I was unable to find any API for getting the make or model of the monitor.

I’m not worried much about X11; it’s possible to get the whole EDID via xrandr 
—-props, which presumably either uses xrandr xcb API or reads it from /sys.

What about getting the output connector name on OS X?  If you connect two 
monitors of the same model, the name won’t be unique there, whereas at least 
the output name is unique on X11.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Michael Zanetti]

On 20.06.2016 15:00, Morten Sorvig wrote:
> 
>> On 17 Jun 2016, at 14:54, Frank Hemer  wrote:
>>
>> Can you give a hint on what causes these glitches and how to avoid them?
>> I'm not talking about general usage of fractional methods for painting here. 
>>
>> For example when drawing to a pixmap (sized for the 'real' screen 
>> resolution) 
>> and then updating just a sub-rectangle of this pixmap, for some (and really 
>> only some) fractional scale factor values there are glitches around that sub-
>> rectangle where the background color of the window shines through.
>> What is causing this?
> 
> I have not analyzed these in detail, but my guess would be rounding errors
> due to fractional coordinates. So you could look at the update code (in 
> QPainter
> or the paint engine) and make sure coordinates are rounded to _include_
> partially covered pixels.
> 
>>
>> What is the reason for not aiming towards supporting fractional scale 
>> factors 
>> on the long run? What is the real challenge here?
>>
> 
> Good question!
> 
> If you ask me I think the Qt project should move towards supporting this 
> (taking
> care to avoid maintenance traps such as the native styles). One of the 
> challenges
> is simply available time and resources for doing the work. But even today Qt 
> Creator
> at QT_SCALE_FACTOR=1.3 is a usable application.
> 
> 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?



signature.asc
Description: OpenPGP digital signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 22 Jun 2016, at 09:17, Shawn Rutledge  wrote:
> 
> 
>> On 21 Jun 2016, at 21:26, Thiago Macieira  wrote:
>> 
>> On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote:
>>> I think using screen names can be a good match for cases where you are
>>> sometimes connecting to external screens, provided that the string returned
>>> by name() is unique for each screen.
>> 
>> It's not. It's always "DP-1" (it reports the connection, not the monitor).
> 
> So far that’s a difference between OS X (which reports the monitor’s model 
> name) and Linux (which reports the output name).  If we could get both, on 
> all OSes (which I’m not sure of), maybe we could format it like “SyncMaster 
> on HDMI-1” or some such.


I was unable to find any API for getting the make or model of the monitor.
Someone who is more familiar with XCB could give the authoritative answer
here.

If this is indeed impossible then users with multiple monitor setups have
to manually maintain multiple QT_SCREEN_SCALE_FACTORS configs, based on
either screen index or connection name.

Morten



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Shawn Rutledge]

> On 21 Jun 2016, at 21:26, Thiago Macieira  wrote:
> 
> On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote:
>> I think using screen names can be a good match for cases where you are
>> sometimes connecting to external screens, provided that the string returned
>> by name() is unique for each screen.
> 
> It's not. It's always "DP-1" (it reports the connection, not the monitor).

So far that’s a difference between OS X (which reports the monitor’s model 
name) and Linux (which reports the output name).  If we could get both, on all 
OSes (which I’m not sure of), maybe we could format it like “SyncMaster on 
HDMI-1” or some such.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Thiago Macieira]

On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote:
> I think using screen names can be a good match for cases where you are
> sometimes connecting to external screens, provided that the string returned
> by name() is unique for each screen.

It's not. It's always "DP-1" (it reports the connection, not the monitor).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 17 Jun 2016, at 22:49, Thiago Macieira  wrote:
> 
> 
> Creator is also a bad citizen (worst of all Qt 5 applications I've tested), 
> but I did not test it again in the scenarios above. When I tested before, I 
> had to find the right combination that would make both the QML and non-QML 
> parts of the UI look reasonable. Under some configurations, the text editor 
> was 
> the right size but the Welcome screen, the left and bottom panels would look 
> too big, etc.

Creator’s lot in life - taking the fall for bugs in Qt :)

Anyway, inconsistencies like these is something I’m seeking to avoid with the
new patches: we want to have uniform scaling for all app content where 
everything
comes out either correct or not. This should make it easier to judge what 
effects
setting options has.

If you’re still seeing things like this even with the most recent patches
(see update below) that’s something I think we should take a closer look at.

> But you apparently removed the ability to set the scaling per-monitor. So 
> this 
> brings Qt back on par with other X11 HiDPI-aware applications. Hence the 
> reply 
> I get from everyone: use Wayland.

Yes. I left that one out in my description, the code was still there.
I made a couple of the changes to the implementaton (see commit de827565)
and included it in the --metrics output.

The configuration workflow is now:

1) Set Qt::AA_EnableHighDpiScaling or QT_AUTO_SCREEN_SCALE_FACTOR=1

   This will use the per-screen logical DPI as reported by the
   platform plugin.

2) If not happy then

2a) Override the global logical DPI: QT_FONT_DPI=N

2b) Use physical DPI: QT_USE_PHYSICAL_DPI=1

2c) Set scale factors manually: 
QT_SCREEN_SCALE_FACTORS=2;1;
QT_SCREEN_SCALE_FACTORS="externalMonitor=2”

This will disregard the DPI values the platform plugin reports for
the screens in question. The screen name in the second form is
QScreen::name(). (Using the screen name is possible already in 5.6).

2d) Perhaps tweak the rounding policy. (factors directly specified in env.
variables are not rounded).


I think using screen names can be a good match for cases where you are
sometimes connecting to external screens, provided that the string returned
by name() is unique for each screen.


Morten
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Samuel Stirtzel via Development]

2016-06-21 14:15 GMT+02:00 Shawn Rutledge :
>
>> On 20 Jun 2016, at 18:09, Thiago Macieira  wrote:
>> 160x90 mm is a valid screen size, correspoding to a 7.2" monitor.
>
> Of course, it’s just suspicious (being a fallback value, apparently), but not 
> impossible.

Unfortunately it's not a fallback value, instead TV manufacturers
commonly only set the aspect ratio (in cm) because one EDID for all
devices is cheaper.
See bullet point d of Adam Jacksons mail about the EDID -> DPI topic:
https://lists.fedoraproject.org/pipermail/devel/2011-October/157671.html


-- 
Regards
Samuel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Maurice Kalinowski]

> 2) Handling fractional scale factors
> 
> This is relevant for e.g. a Windows setting of 250%, corresponding to a scale
> factor of 2.5. Presenting a fractional scale factor to the app may cause
> graphics glitches, so we round it to the nearest integer, using qRound.
> 
> However, mathematically correct rounding may not be the best kind of
> correct in this case. In particular we should consider rounding factors of .5
> down instead of up. The effect would be presenting an UI that is visually
> slightly smaller than it should be, over the current behavior of presenting an
> UI that is slightly larger.
> 
> In addition we have the option of tweaking the DPI reported to the
> application to account for the remainder from the rounding.
> So for the 250% case we can report a devicePixelRatio of 2 and a DPI of 144.
> This relies on the existing DPI handling support (fonts scale automatically,
> rest of UI may not), but since the offset from the base DPI is small it might 
> be
> OK.
> 
> Finally, we should consider adding an option to simply let the fractional 
> scale
> factor through. We have user reports of applications that work fine with such
> factors, save for one or two bugs in Qt. These are typically custom-styled
> applications that do not rely on the Qt platform styles.
> Allowing this as an option would not mean that fractional factors are
> supported in Qt (for the formal meaning of “supported"), nor that we
> necessarily spend time on fixing related issues.
> 
[Kalinowski Maurice] 
+1 from my side. On WinRT / Windows Phone / UWP, you will hardly see an integer 
scale factor. That causes troubles when developers want to have native scaling 
and we forbid this internally.

As you mentioned, we have users who patches this part and they seem to be happy 
with what works then already. If painting glitches appear, we need to be sure 
to document why that is and what potential workarounds one could apply.

BR,
Maurice

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Shawn Rutledge]

> On 20 Jun 2016, at 18:09, Thiago Macieira  wrote:
> 
> On segunda-feira, 20 de junho de 2016 14:30:19 PDT Shawn Rutledge wrote:
>> Don’t you think there should be a quirks database somewhere (outside of Qt)
>> which corrects these cases?  The TV model can be identified, right?
> 
>> X does it, but that’s not a broad enough scope to cover Wayland.
>> 
>> https://wiki.ubuntu.com/X/Quirks#Monitor_Quirks 
>> 
>> Maybe it could be done with udev rules or something.  If there is really not
>> yet a proper solution on Linux, there should be, IMO.
> 
> We would need a correction database, not just a quirks one.

I thought that in common usage in the context of device drivers and their 
configuration, “quirks” are certain characteristics that are 
overridden/corrected for certain identifiable devices.

> 160x90 mm is a valid screen size, correspoding to a 7.2" monitor.

Of course, it’s just suspicious (being a fallback value, apparently), but not 
impossible.

But assuming the model of your TV is unique and can also be read over EDID 
(like most monitors), the size could be corrected.  I have the same issue with 
a Samsung SyncMaster 2494HM at the office, and have been wondering why X 
doesn’t “quirk” it by default.  From the xorg log on Arch Linux:

[   266.313] (II) RADEON(0): EDID for output HDMI-0
[   266.313] (II) RADEON(0): Manufacturer: SAM  Model: 4d5  Serial#: 1263088180
[   266.313] (II) RADEON(0): Year: 2010  Week: 38
…
[   266.313] (II) RADEON(0): Supported detailed timing:
[   266.313] (II) RADEON(0): clock: 148.5 MHz   Image Size:  160 x 90 mm
[   266.313] (II) RADEON(0): h_active: 1920  h_sync: 2008  h_sync_end 2052 
h_blank_end 2200 h_border: 0
[   266.313] (II) RADEON(0): v_active: 1080  v_sync: 1084  v_sync_end 1089 
v_blanking: 1125 v_border: 0
…

I’m guessing that "Manufacturer: SAM  Model: 4d5” is probably enough to 
identify it.  Or use the year and week if necessary.  There would need to be a 
web site to give feedback to add to the quirks database (similar to the way you 
can register unidentified USB devices on linux-usb.org): if various people with 
the same monitor, with different production dates, report the same problem, a 
pattern would emerge: for what period of time was this company making this 
mistake.  Then it could go into the quirks.  Or some distros could auto-report 
the EDIDs that are discovered - then it would be a matter of auditing them to 
see how many are uniquely identifiable and which of those are likely to contain 
wrong values for physical size.

I do also see several cases like this in the log:

[   266.313] (II) Quirked EDID physical size to 0x0 cm

which is not very useful…

But quirks should IMO belong to the kernel, or to udev (depending whether udev 
can see when any kind of monitor is hotplugged), or to some library that 
corrects monitor EDIDs, not just to X.  Qt could do it, cross-platform even, 
but we shouldn’t have to.

Ah (googles it again) here we go:

https://wiki.ubuntu.com/X/MonitorsDatabaseOnline

Sounds good.  But somehow it hasn’t resulted in corrected EDIDs being available 
everywhere.  But Ubuntu 16.04 does correct the EDID for my monitor!  I hadn’t 
noticed before.  (Maybe it knows about your TV too?)  And the qscreen manual 
test reports correct dimensions.  So, the other distros ought to be reusing 
Ubuntu's quirks database, I guess.  But maybe it’s only an online database so 
far.  On KDE though, http://www.simonzone.com/software/guidance/ was supposed 
to be using it (although I don’t see evidence of that in the code).  But I 
suppose there’s a political problem with having the latest (e.g.) KDE control 
panel depend on some Ubuntu online service to look up monitor EDID corrections. 
 (So far I’m having trouble finding the URL for that service.)  So ideally 
Canonical ought to give permission to package up their database and allow 
shipping it with other distros too; or maybe it can start to be hosted on a 
wider-community website.  The downside is that the updates to the quirks that 
ship with distros would tend to be slow (like adding USB IDs so that lsusb 
knows about them - it takes at least a few months, typically).

http://forums.fedoraforum.org/showpost.php?s=4dd2d2dbdc3131f2ad45a3f23b82d2d6=1695752
 has some different info.  I found that this works as a way of reading the EDID 
at any time:

parse-edid < 
/sys/devices/pci:00/:00:07.0/:05:00.0/drm/card0/card0-HDMI-A-1/edid

It seems that nVidia X drivers have a config option for overriding EDID, but 
the others apparently don’t.  If they all did, the quirks could go in 
/usr/share/X11/xorg.conf.d/10-quirks.conf.  But anyway, we want a solution that 
goes beyond X.

Microsoft also has inf files for correcting EDID:

https://msdn.microsoft.com/en-us/library/windows/hardware/jj133967(v=vs.85).aspx

so if manufacturers (sometimes) already provide the inf files, maybe Linux 
ought to be able to use those somehow.  

Re: [Development] Revisiting high-DPI configuration options

[Thiago Macieira]

On segunda-feira, 20 de junho de 2016 14:30:19 PDT Shawn Rutledge wrote:
> Don’t you think there should be a quirks database somewhere (outside of Qt)
> which corrects these cases?  The TV model can be identified, right?
 
> X does it, but that’s not a broad enough scope to cover Wayland.
> 
> https://wiki.ubuntu.com/X/Quirks#Monitor_Quirks 
> 
> Maybe it could be done with udev rules or something.  If there is really not
> yet a proper solution on Linux, there should be, IMO.

We would need a correction database, not just a quirks one.

160x90 mm is a valid screen size, correspoding to a 7.2" monitor.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Shawn Rutledge]

> On 17 Jun 2016, at 22:49, Thiago Macieira  wrote:
> 
>> - Run "./highdpi --metrics", or test with an application.
> 
> See 3 scenarios attached. I'll send a fourth scenario later, when I try at 
> home with my 45" TV that reports its size as 160 x 90 mm.

Don’t you think there should be a quirks database somewhere (outside of Qt) 
which corrects these cases?  The TV model can be identified, right?

X does it, but that’s not a broad enough scope to cover Wayland.

https://wiki.ubuntu.com/X/Quirks#Monitor_Quirks 

Maybe it could be done with udev rules or something.  If there is really not 
yet a proper solution on Linux, there should be, IMO.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 17 Jun 2016, at 14:54, Frank Hemer  wrote:
> 
> Can you give a hint on what causes these glitches and how to avoid them?
> I'm not talking about general usage of fractional methods for painting here. 
> 
> For example when drawing to a pixmap (sized for the 'real' screen resolution) 
> and then updating just a sub-rectangle of this pixmap, for some (and really 
> only some) fractional scale factor values there are glitches around that sub-
> rectangle where the background color of the window shines through.
> What is causing this?

I have not analyzed these in detail, but my guess would be rounding errors
due to fractional coordinates. So you could look at the update code (in QPainter
or the paint engine) and make sure coordinates are rounded to _include_
partially covered pixels.

> 
> What is the reason for not aiming towards supporting fractional scale factors 
> on the long run? What is the real challenge here?
> 

Good question!

If you ask me I think the Qt project should move towards supporting this (taking
care to avoid maintenance traps such as the native styles). One of the 
challenges
is simply available time and resources for doing the work. But even today Qt 
Creator
at QT_SCALE_FACTOR=1.3 is a usable application.

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.

Morten



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Thiago Macieira]

> - Run "./highdpi --metrics", or test with an application.

See 3 scenarios attached. I'll send a fourth scenario later, when I try at 
home with my 45" TV that reports its size as 160 x 90 mm.

Software scaling (scenario 3) is achieved with:
$ xrandr --output DP-1 --mode 1920x1080 --scale 2x2 --panning 3840x2160+3200+0

Note that 3840x2160 = 2 * 1920x1080 and 3200 is the width of my left (HighDPI) 
monitor.

> - X11: Check if using the logical or physical DPI works for your displays
>QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_USE_PHYSICAL_DPI=0|1 ./highdpi
> --metrics

See above.
 
> - X11/Windows: Test how fractional scale factors work (if applicable)
>QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough
> ./applicaiton
 
> - X11 (mostly): Are you using non-Qt applications on the high-DPI displays?
> How do you configure them?

Yes. Chromium and Firefox apparently configured themselves, after I set the X 
DPI (X is started with the option -dpi 216). I tried an extension to Firefox, 
but it wasn't necessary and only made things worse. I didn't try to restart X 
without the -dpi option, I only used xrandr to set it back to 96 when I 
calculated Scenario 2, so YMMV.

For other GTK applications, I had to set the environment:

$ cat ~/.config/plasma-workspace/env/var.sh
export CLUTTER_SCALE=2
export GDK_SCALE=2
export QT_MESSAGE_PATTERN='[%{time boot}] %{appname}(%{pid} %{threadid}):%{if-
category} %{category}:%{endif}%{message}'
export QT_SCREEN_SCALE_FACTORS='2;2'

For Qt 4 applications still left in the system, the only thing that worked was 
setting the X DPI to 216. The value 216 is lower than the actual screen DPI, 
but provides a reasonable experience. It was trial and error. Also, 216/96 = 
2.25, which should help with rounding down.

All non-Qt apps only work in Scenario 3 (software scaling of the external 
monitor). In Scenario 1 with QT_SCREEN_SCALE_FACTORS='2;1', Qt 5.6+ apps work 
fine, but non-Qt apps look huge on the external, normal-DPI monitor.

Creator is also a bad citizen (worst of all Qt 5 applications I've tested), 
but I did not test it again in the scenarios above. When I tested before, I 
had to find the right combination that would make both the QML and non-QML 
parts of the UI look reasonable. Under some configurations, the text editor was 
the right size but the Welcome screen, the left and bottom panels would look 
too big, etc.

> As before, QT_SCALE_FACTOR can be used to set any scale factor for testing,
> and  QT_FONT_DPI can be use the set the logical DPI (now expanded to work
> on Windows and macOS in addition to X11).

But you apparently removed the ability to set the scaling per-monitor. So this 
brings Qt back on par with other X11 HiDPI-aware applications. Hence the reply 
I get from everyone: use Wayland.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
== Scenario 1 ==
* High-DPI laptop screen, regular DPI external monitor
* No X scaling
* Monitors report correct size

eDP-1 connected primary 3200x1800+0+0 (normal left inverted right x axis y 
axis) 294mm x 165mm
DP-1 connected 1920x1080+3200+0 (normal left inverted right x axis y axis) 
598mm x 336mm panning 1920x1080+3200+0

$ xdpyinfo| grep dots
  resolution:217x218 dots per inch

=== With clear environment: ===
eDP-1:
widget devicePixelRatio: 1
widget logicalDpi: 217

platform screen logicalDpi: 217.109
platform screen logicalBaseDpi: 96
platform screen devicePixelRatio: 1
platform screen physicalDpi: 276.777

QT_FONT_DPI: 
QT_SCALE_FACTOR: 
QT_AUTO_SCREEN_SCALE_FACTOR: 0
QT_USE_PHYSICAL_DPI: 
QT_SCALE_FACTOR_ROUNDING_POLICY: 
QT_DPI_ADJUSTMENT_POLICY: 

DP-1:
widget devicePixelRatio: 1
widget logicalDpi: 217

platform screen logicalDpi: 217.109
platform screen logicalBaseDpi: 96
platform screen devicePixelRatio: 1
platform screen physicalDpi: 81.5973

QT_FONT_DPI: 
QT_SCALE_FACTOR: 
QT_AUTO_SCREEN_SCALE_FACTOR: 0
QT_USE_PHYSICAL_DPI: 
QT_SCALE_FACTOR_ROUNDING_POLICY: 
QT_DPI_ADJUSTMENT_POLICY: 


The window looks normal on the high-DPI screen, but huge on the normal monitor.

=== With QT_AUTO_SCREEN_SCALE_FACTOR=1: ===
eDP-1:
widget devicePixelRatio: 4
widget logicalDpi: 121

platform screen logicalDpi: 217.109
platform screen logicalBaseDpi: 96
platform screen devicePixelRatio: 1
platform screen physicalDpi: 276.777

QT_FONT_DPI: 
QT_SCALE_FACTOR: 
QT_AUTO_SCREEN_SCALE_FACTOR: 1
QT_USE_PHYSICAL_DPI: 
QT_SCALE_FACTOR_ROUNDING_POLICY: 
QT_DPI_ADJUSTMENT_POLICY: 

DP-1:
widget devicePixelRatio: 4
widget logicalDpi: 121

platform screen logicalDpi: 217.109
platform screen logicalBaseDpi: 96
platform screen devicePixelRatio: 1
platform screen physicalDpi: 81.5973

QT_FONT_DPI: 
QT_SCALE_FACTOR: 
QT_AUTO_SCREEN_SCALE_FACTOR: 1
QT_USE_PHYSICAL_DPI: 
QT_SCALE_FACTOR_ROUNDING_POLICY: 
QT_DPI_ADJUSTMENT_POLICY: 

The window looks huge on the high-DPI screen and "huger" on the normal one.

=== With QT_SCREEN_SCALE_FACTORS='2;1' ===

Re: [Development] Revisiting high-DPI configuration options

[Thiago Macieira]

On sexta-feira, 17 de junho de 2016 12:06:06 PDT Morten Sorvig wrote:
> It is my impression that getting per-screen logical DPI values from X11
> is difficult. I’d very much appreciate feed back here from users on
> various desktops (KDE, GONME, other): Are there settings we can use? We
> need an API or read a config file.

There are expicitly no global settings on X11. There are two main settings, 
one for each of those environments: one in GSettings and the other is Qt's 
own. And as far as I can tell from the GTK side, it does not support mixing 
HiDPI monitors with non-HiDPI ones, something that Qt does.

However, since it doesn't, it means I can't use Qt's feature.

The other problem is that environment variables are not dynamic enough. What 
happens if I frequently connect to a HiDPI external monitor and a non-HiDPI 
one? (e.g., one in the office, the other at home)

Everyone I ask about this gives the same answer: Wayland.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Frank Hemer]

Hi Morten,

On Friday 17 June 2016 12:06:06 Morten Sorvig wrote:
> Hi all,
> 
> After shipping the high-dpi update in 5.6 we’ve gotten several reports
> that application scaling does not always come out as intended (see
> QTBUG-52318, QTBUG-53416, QTBUG-53500, and QTBUG-54144). I’d like to
> take a look at this again.
> 
> There are a lot of different configurations out there so I think one of
> the things we need is field testing to verify that what we are implementing
> works as intended. Ideally testers should be willing to apply patches and
> recompile Qt.
> 
> The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to
> focus on two aspects:
> 
> 1) Automatic scale factor configuration based on system settings.
> 2) Handling fractional scale factors (rounding).
> 
> 
> 1) Scale factor configuration. This is an issue on some platforms:
> 
> - (Windows has landed on using per-screen logical DPI and should be fine.)
> 
> - Android: We have some reports of Qt on some devices getting incorrect
> scale factors. If you have such as device available for testing I’d like
> to hear from you.
> 
> - X11: Currently uses _both_ logical and physical DPI. This means the
> application comes out wrong if either are incorrectly set.
> 
> Physical DPI is great for getting an accurate per-screen scale factor
> but has two flaws: We can’t always trust it (and we don’t know _when_
> we can trust it), and it does not respect user settings (including our
> own QT_FONT_DPI).
> 
> I suggest we move x11 over to using logical DPI (similar to Windows),
> perhaps having physical DPI as an option.
> 
> It is my impression that getting per-screen logical DPI values from X11
> is difficult. I’d very much appreciate feed back here from users on
> various desktops (KDE, GONME, other): Are there settings we can use? We
> need an API or read a config file.
> 
> 
> 2) Handling fractional scale factors
> 
> This is relevant for e.g. a Windows setting of 250%, corresponding to
> a scale factor of 2.5. Presenting a fractional scale factor to the app
> may cause graphics glitches, so we round it to the nearest integer,
> using qRound.

Can you give a hint on what causes these glitches and how to avoid them?
I'm not talking about general usage of fractional methods for painting here. 

For example when drawing to a pixmap (sized for the 'real' screen resolution) 
and then updating just a sub-rectangle of this pixmap, for some (and really 
only some) fractional scale factor values there are glitches around that sub-
rectangle where the background color of the window shines through.
What is causing this?

> However, mathematically correct rounding may not be the best kind of
> correct in this case. In particular we should consider rounding factors
> of .5 down instead of up. The effect would be presenting an UI that
> is visually slightly smaller than it should be, over the current
> behavior of presenting an UI that is slightly larger.
> 
> In addition we have the option of tweaking the DPI reported to the
> application to account for the remainder from the rounding.
> So for the 250% case we can report a devicePixelRatio of 2 and a
> DPI of 144. This relies on the existing DPI handling support (fonts
> scale automatically, rest of UI may not), but since the offset from
> the base DPI is small it might be OK.
> 
> Finally, we should consider adding an option to simply let the fractional
> scale factor through. We have user reports of applications that work
> fine with such factors, save for one or two bugs in Qt. These are typically
> custom-styled applications that do not rely on the Qt platform styles.
> Allowing this as an option would not mean that fractional factors are
> supported in Qt (for the formal meaning of “supported"), nor that we
> necessarily spend time on fixing related issues.

What is the reason for not aiming towards supporting fractional scale factors 
on the long run? What is the real challenge here?

> How do I test the new implementation?
> 
> - Check out the patches for 5.6: (this is the last change in the series)
> https://codereview.qt-project.org/#/c/157175/
> 
> - Compile qtbase and tests/manual/highdpi
> 
> - Run "./highdpi --metrics", or test with an application.
> 
> - X11: Check if using the logical or physical DPI works for your displays
>QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_USE_PHYSICAL_DPI=0|1 ./highdpi
> --metrics
 
> - X11/Windows: Test how fractional scale factors work (if applicable)
>QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough
> ./applicaiton
 
> - X11 (mostly): Are you using non-Qt applications on the high-DPI displays?
> How do you configure them?
> 
> As before, QT_SCALE_FACTOR can be used to set any scale factor for testing,
> and
 QT_FONT_DPI can be use the set the logical DPI (now expanded to work
> on Windows and macOS in addition to X11).
> 
> Please report back here, or directly to me, or on tracking bug QTBUG-53022.
> Both reports of 

[Development] Revisiting high-DPI configuration options

[Morten Sorvig]

Hi all,

After shipping the high-dpi update in 5.6 we’ve gotten several reports
that application scaling does not always come out as intended (see
QTBUG-52318, QTBUG-53416, QTBUG-53500, and QTBUG-54144). I’d like to
take a look at this again.

There are a lot of different configurations out there so I think one of
the things we need is field testing to verify that what we are implementing
works as intended. Ideally testers should be willing to apply patches and
recompile Qt.

The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to
focus on two aspects:

1) Automatic scale factor configuration based on system settings.
2) Handling fractional scale factors (rounding).


1) Scale factor configuration. This is an issue on some platforms:

- (Windows has landed on using per-screen logical DPI and should be fine.)

- Android: We have some reports of Qt on some devices getting incorrect
scale factors. If you have such as device available for testing I’d like
to hear from you.

- X11: Currently uses _both_ logical and physical DPI. This means the
application comes out wrong if either are incorrectly set.

Physical DPI is great for getting an accurate per-screen scale factor
but has two flaws: We can’t always trust it (and we don’t know _when_
we can trust it), and it does not respect user settings (including our
own QT_FONT_DPI).

I suggest we move x11 over to using logical DPI (similar to Windows),
perhaps having physical DPI as an option.

It is my impression that getting per-screen logical DPI values from X11
is difficult. I’d very much appreciate feed back here from users on
various desktops (KDE, GONME, other): Are there settings we can use? We
need an API or read a config file.


2) Handling fractional scale factors

This is relevant for e.g. a Windows setting of 250%, corresponding to
a scale factor of 2.5. Presenting a fractional scale factor to the app
may cause graphics glitches, so we round it to the nearest integer,
using qRound.

However, mathematically correct rounding may not be the best kind of
correct in this case. In particular we should consider rounding factors
of .5 down instead of up. The effect would be presenting an UI that
is visually slightly smaller than it should be, over the current
behavior of presenting an UI that is slightly larger.

In addition we have the option of tweaking the DPI reported to the
application to account for the remainder from the rounding.
So for the 250% case we can report a devicePixelRatio of 2 and a
DPI of 144. This relies on the existing DPI handling support (fonts
scale automatically, rest of UI may not), but since the offset from
the base DPI is small it might be OK.

Finally, we should consider adding an option to simply let the fractional
scale factor through. We have user reports of applications that work
fine with such factors, save for one or two bugs in Qt. These are typically
custom-styled applications that do not rely on the Qt platform styles.
Allowing this as an option would not mean that fractional factors are
supported in Qt (for the formal meaning of “supported"), nor that we
necessarily spend time on fixing related issues.


How do I test the new implementation?

- Check out the patches for 5.6: (this is the last change in the series)
https://codereview.qt-project.org/#/c/157175/

- Compile qtbase and tests/manual/highdpi

- Run "./highdpi --metrics", or test with an application.

- X11: Check if using the logical or physical DPI works for your displays
   QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_USE_PHYSICAL_DPI=0|1 ./highdpi --metrics
  
- X11/Windows: Test how fractional scale factors work (if applicable)
   QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough 
./applicaiton

- X11 (mostly): Are you using non-Qt applications on the high-DPI displays?
How do you configure them?

As before, QT_SCALE_FACTOR can be used to set any scale factor for testing, and
QT_FONT_DPI can be use the set the logical DPI (now expanded to work on Windows
and macOS in addition to X11).

Please report back here, or directly to me, or on tracking bug QTBUG-53022.
Both reports of success or brokenness are interesting. Include the output from
"./highdpi —metrics” with the report.

Also feel free to ask questions if anything is unclear.

Thanks!
Morten



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development