Discussion:
Revisiting high-DPI configuration options
(too old to reply)
Morten Sorvig
2016-06-17 12:06:06 UTC
Permalink
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
Frank Hemer
2016-06-17 12:54:45 UTC
Permalink
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 success or brokenness are interesting. Include the output
> from "./highdpi —metrics” with the report.

I really appreciate your effort in improving this:-)

Frank
Morten Sorvig
2016-06-20 13:00:16 UTC
Permalink
> On 17 Jun 2016, at 14:54, Frank Hemer <***@hemer.org> 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
Michael Zanetti
2016-06-22 08:30:21 UTC
Permalink
On 20.06.2016 15:00, Morten Sorvig wrote:
>
>> On 17 Jun 2016, at 14:54, Frank Hemer <***@hemer.org> 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?
Morten Sorvig
2016-06-22 12:46:09 UTC
Permalink
> On 22 Jun 2016, at 10:30, Michael Zanetti <***@canonical.com> 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
Michael Zanetti
2016-06-22 13:30:52 UTC
Permalink
On 22.06.2016 14:46, Morten Sorvig wrote:
>
>> On 22 Jun 2016, at 10:30, Michael Zanetti <***@canonical.com> 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
Morten Sorvig
2016-06-24 21:39:49 UTC
Permalink
> On 22 Jun 2016, at 15:30, Michael Zanetti <***@canonical.com> 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
ekke
2016-06-22 13:32:24 UTC
Permalink
Am 22.06.16 um 14:46 schrieb Morten Sorvig:
>> On 22 Jun 2016, at 10:30, Michael Zanetti <***@canonical.com> 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
>
Morten Sorvig
2016-06-23 06:29:22 UTC
Permalink
> On 22 Jun 2016, at 15:32, ekke <***@ekkes-corner.org> 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
Thiago Macieira
2016-06-17 15:41:35 UTC
Permalink
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
Morten Sorvig
2016-06-20 13:13:16 UTC
Permalink
> On 17 Jun 2016, at 17:41, Thiago Macieira <***@intel.com> wrote:
>
>
> Everyone I ask about this gives the same answer: Wayland.


I agree, Wayland solves the problem at the correct place in the software stack.

So in this light what we are doing for Qt on X11 can be considered a workaround
while we wait for proper windowing system support. Of course X11 is going to be
in use for a long time and we should make Qt work as well as possible here,
even if we have to give up automatic configuration.

Morten
Thiago Macieira
2016-06-17 20:49:59 UTC
Permalink
> - 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
Shawn Rutledge
2016-06-20 14:30:19 UTC
Permalink
> On 17 Jun 2016, at 22:49, Thiago Macieira <***@intel.com> 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.
Thiago Macieira
2016-06-20 16:09:51 UTC
Permalink
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
Shawn Rutledge
2016-06-21 12:15:29 UTC
Permalink
> On 20 Jun 2016, at 18:09, Thiago Macieira <***@intel.com> 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&p=1695752 has some different info. I found that this works as a way of reading the EDID at any time:

parse-edid < /sys/devices/pci0000:00/0000:00:07.0/0000: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. https://wiki.ubuntu.com/X/MonitorsDatabaseOnline says that DisplayConfigGtk can do that.

There’s even a utility to rewrite the EDID info on the monitor, if one dares: https://github.com/bulletmark/edid-rw

Anyway it looks like Ubuntu did something good for their own users, and then it didn’t get any further, so far. Does anyone know who is in a position to negotiate a solution for all distros? Otherwise Qt will continue to have ongoing trouble with this. I don’t want to accept that there is no solution, and that monitor sizes will never be trustworthy.
Morten Sorvig
2016-06-22 08:53:48 UTC
Permalink
> On 21 Jun 2016, at 15:24, Samuel Stirtzel via Development <***@qt-project.org> wrote:
>
> 2016-06-21 14:15 GMT+02:00 Shawn Rutledge <***@qt.io>:
>>
>>> On 20 Jun 2016, at 18:09, Thiago Macieira <***@intel.com> 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
Morten Sorvig
2016-06-21 18:02:05 UTC
Permalink
> On 17 Jun 2016, at 22:49, Thiago Macieira <***@intel.com> 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
Thiago Macieira
2016-06-21 19:26:50 UTC
Permalink
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
Shawn Rutledge
2016-06-22 07:17:47 UTC
Permalink
> On 21 Jun 2016, at 21:26, Thiago Macieira <***@intel.com> 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.
Morten Sorvig
2016-06-22 08:21:40 UTC
Permalink
> On 22 Jun 2016, at 09:17, Shawn Rutledge <***@qt.io> wrote:
>
>
>> On 21 Jun 2016, at 21:26, Thiago Macieira <***@intel.com> 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
Shawn Rutledge
2016-06-22 08:43:14 UTC
Permalink
> On 22 Jun 2016, at 10:21, Morten Sorvig <***@qt.io> wrote:
>
>
>> On 22 Jun 2016, at 09:17, Shawn Rutledge <***@qt.io> wrote:
>>
>>
>>> On 21 Jun 2016, at 21:26, Thiago Macieira <***@intel.com> 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.
Maurice Kalinowski
2016-06-21 12:21:21 UTC
Permalink
> 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
Prav
2016-07-19 08:57:20 UTC
Permalink
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 ;)
Frank Hemer
2016-07-19 10:07:31 UTC
Permalink
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
Edward Welbourne
2016-07-19 10:38:04 UTC
Permalink
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.
Ulf Hermann
2016-07-19 10:48:02 UTC
Permalink
> 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
Shawn Rutledge
2016-07-19 12:58:37 UTC
Permalink
> On 19 Jul 2016, at 10:57, Prav <***@programist.ru> 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 taking over those key and mouse shortcuts), and remember the last setting. But maybe it’s controversial to push QSettings into even broader use… some think it’s obsolete and don’t know what to replace it with. Some want to use JSON. And what about touch-oriented apps? We can’t take over the pinch-zoom gesture for the single purpose of scaling text sizes, because each app can use that gesture in its own way. Maybe we could at least make it easy to declare a handler which makes the pinch gesture do that, if that’s what you want, and your app doesn’t have another use case for pinch. 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.

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

Yes, exactly.

The same goes for switching between light and dark themes. It should be system-wide and as effortless as possible. When I use my laptop on my morning commute, I want a light theme, and typically a dark one on the way home, depending on the season and the weather. Android is wrong - they enforce inconsistency and lack of choice by letting every application hard-code the theme. Creator is wrong for making me restart it if I change the UI theme. And everyone else is wrong for not making a handy system-wide toggle.

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

We can’t say that DPI is never important though. The consensus so far seems to be that some apps need accurate scaling, while most don’t. Qt has to support both, and the one doesn’t prevent the other.
Prav
2016-07-19 23:56:52 UTC
Permalink
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!
Edward Welbourne
2016-07-20 09:12:53 UTC
Permalink
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.

Then again, our SVG support is embarrassingly poor,

Eddy.
Michael Zanetti
2016-07-20 09:23:06 UTC
Permalink
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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Edward Welbourne
2016-07-20 10:47:48 UTC
Permalink
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.
Prav
2016-07-20 10:03:03 UTC
Permalink
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).
Thiago Macieira
2016-07-20 16:47:23 UTC
Permalink
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
Prav
2016-07-21 20:11:28 UTC
Permalink
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").
Thiago Macieira
2016-07-20 16:41:47 UTC
Permalink
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
Prav
2016-07-20 17:13:07 UTC
Permalink
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.
Konstantin Tokarev
2016-07-20 17:15:55 UTC
Permalink
20.07.2016, 20:12, "Prav" <***@programist.ru>:
> 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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Regards,
Konstantin
Thiago Macieira
2016-07-20 17:44:16 UTC
Permalink
On quarta-feira, 20 de julho de 2016 20:13:07 PDT Prav wrote:
> 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?

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.

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

I don't know what Material is, but whatever it is, I doubt it allows you to
make that generalised assumption.

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

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Prav
2016-07-20 18:03:48 UTC
Permalink
> 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.
Thiago Macieira
2016-07-20 18:08:25 UTC
Permalink
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
Konstantin Tokarev
2016-07-20 18:21:48 UTC
Permalink
20.07.2016, 21:08, "Thiago Macieira" <***@intel.com>:
> 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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Regards,
Konstantin
Thiago Macieira
2016-07-20 21:03:11 UTC
Permalink
On quarta-feira, 20 de julho de 2016 21:21:48 PDT Konstantin Tokarev wrote:
> 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

And who do you think wrote QtSvg in the first place? Same person :-)

(Zack, are you still lurking around in the ML?)

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Uwe Rathmann
2016-07-20 19:00:18 UTC
Permalink
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
Stephen Chu
2016-07-26 18:53:20 UTC
Permalink
On 7/20/16, 5:12 AM, "Development on behalf of Edward Welbourne" <development-bounces+stephen.chu=***@qt-project.org on behalf of ***@qt.io> 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.
Nikita Krupenko
2016-07-26 23:49:31 UTC
Permalink
2016-07-19 15:58 GMT+03:00 Shawn Rutledge <***@qt.io>:
>> 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-
Thiago Macieira
2016-07-27 01:02:07 UTC
Permalink
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
Nikita Krupenko
2016-07-27 02:56:52 UTC
Permalink
2016-07-27 4:02 GMT+03:00 Thiago Macieira <***@intel.com>:
> 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.
Thiago Macieira
2016-07-27 03:21:11 UTC
Permalink
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 <***@intel.com>:
> > 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
Randall O'Reilly
2016-07-27 03:21:48 UTC
Permalink
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 <***@gmail.com> wrote:
>
> 2016-07-27 4:02 GMT+03:00 Thiago Macieira <***@intel.com>:
>> 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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Morten Sorvig
2016-07-19 13:04:46 UTC
Permalink
> On 19 Jul 2016, at 10:57, Prav <***@programist.ru> 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
Morten Sorvig
2016-07-20 11:54:08 UTC
Permalink
> On 20 Jul 2016, at 12:47, Edward Welbourne <***@qt.io> 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
Edward Welbourne
2016-07-20 12:52:43 UTC
Permalink
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.
Morten Sorvig
2016-07-20 12:23:57 UTC
Permalink
> On 19 Jul 2016, at 14:58, Shawn Rutledge <***@qt.io> 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.


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

Yes, we are waiting :) Display pixel density is a rendering detail and should
not affect layouts or window sizes. Some windowing systems are not there yet
and in those cases we may be in the business of resising on screen change.


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

You may be in a minority here. I think the most common case is similarly
sized fonts (visually) on different displays.

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


This is also in the “document” domain. It’s OK if the application UI is not exactly physically calibrated.

Morten
Morten Sorvig
2016-07-20 13:13:08 UTC
Permalink
> On 20 Jul 2016, at 14:51, André Somers <***@familiesomers.nl> wrote:
>
>
>
> Op 20/07/2016 om 14:23 schreef Morten Sorvig:
>>> On 19 Jul 2016, at 14:58, Shawn Rutledge <***@qt.io> 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
Morten Sorvig
2016-07-20 13:10:44 UTC
Permalink
> On 20 Jul 2016, at 14:52, Edward Welbourne <***@qt.io> 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
Loading...