Web lists-archives.com

Re: GSoC Project Proposal: Make High-DPI awesome






On Thu, Mar 23, 2017 at 5:16 AM, Lukas Hetzenecker <lukas@xxxxxxxxxxxxxx> wrote:
Hello,

On 2017-03-22 08:03, Thiago Macieira wrote:
I have only one application left with problems and that's krdc: when I tell it
to create a display (for example) 640x480, it does that in device-independent
pixels, so it actually creates an area 1280x960, which is 4x bigger than the
display it is going to get from the network and embed from vncviewer.

All other applications are working fine now that I submitted this Qt patch:
https://codereview.qt-project.org/188493

I've now applied this patch on top of the current Qt 5.8 branch and unfortunately can
not confirm that all applications are working.

Note that fractional scaling is not supported by Qt. You can do 1x or 2x, but
nothing in-between.

I know the Qt documentation mentions this, but when the "Scale Display" slider
is set to e.g. 1.6 KDE sets the environment variable QT_SCREEN_SCALE_FACTORS
to "DVI-I-0=1.6;DVI-I-1=1.6;HDMI-0=1.6;DP-0=1.6;DVI-D-0=1.6;DP-1=1.6;"
There are also noticable differences between 1.6 and 1.8, so the fractional has
an actual effect.

However I understand that this is an unsupported configuration.
Therefore I set it back to 2.0 and even than I could reproduce the following bugs:

* kdegraphics/gwenview
- https://bugs.kde.org/show_bug.cgi?id=373178
- screenshot comparision: https://drive.google.com/file/d/0BwXqDXwyptm8LU9XcjdUOGZ1LWM/view
- (left is scale 1.0, right is scale 2.0)

Pictures and thumbnails are blurred.
In lib/imagescaler.cpp ImageScaler::scaleRect are scaled to e.g. 500x500px,
because the devicePixelRatio is not taken into account when scaling the
image. As far as I've seen it, the right way would be to scale to
width() * devicePixelRatio, height() * devicePixelRatio, which results in an
1000x1000px image. After calling QPixmap->setDevicePixelRatio the QPainter
draw this correctly.

* kdegraphics/okular
- https://bugs.kde.org/show_bug.cgi?id=362856
- screenshot comparision: https://drive.google.com/file/d/0BwXqDXwyptm8cXBXZm1YSDBnNFk/view
- (left is scale 1.0, right is scale 2.0)

Similar rendering problems happen in Okular. The document is blurry and barely readable.

* systemsettings
- https://bugs.kde.org/show_bug.cgi?id=366451
- e.g. https://drive.google.com/open?id=0BwXqDXwyptm8Z3U3OW1nVzRIU2s

Blurry fonts and other artefacts in systemsettings, although I suspect
the cause for this issue might be in another KDE framework/widget library.
Setting the scale factor to 2.0 improves the situation, but some issues
still persist.

* plasmashell
- https://bugs.kde.org/show_bug.cgi?id=366451

There are still several issues in plasma, I can confirm the blurry rendering
of the shutdown dialog. Again improvements with scale factor 2.0.


I can further reproduce the following bugs:
* kdepim/korganizer
- https://bugs.kde.org/show_bug.cgi?id=353240

Not only are the day labels cut off, but also icons appear blurry.

* konsole
- https://bugs.kde.org/show_bug.cgi?id=373232

* systemsettings / Scale Display UI

Even the scale display UI itself has rendering issues.

This list should just highlight a few examples, there are still a few
other places where things are broken.

So to summarize, applications still don't behave correctly on High-DPI screens.

It isn't clear if non-integer scale factors should be supported (at least the
settings UI does not mention that this could cause problems).

E.g. Java FX (starting from Java 9) Applications check the GDK_SCALE
environment variable, which by default isn't set. Also some applications
have in my experience problems if QT_SCREEN_SCALE_FACTORS is set (e.g.
VLC & JetBrains Toolbox)

VirtualBox has the same problem I described for krdc above. I didn't see a
problem with VLC, but I suspect it would be the exact same issue.

I can confirm problems with VLC and VirtualBox too.

I especially like the following parts of your proposal:
* Polishing user interface for HiDPI settings. Extend it, so it allows
  different scale factors for multiple screens. [my external 27" 4K
Monitor could need a smaller scaling factor than my 15" 4K Laptop Screen]

Not supported by Qt. Like I said, you can have 1 or 2, but not fractional.
There's a patch for Qt by Morten that enables this, but you'll see plenty of
problems because of rounding errors. So, don't.

Supporting different scaling depending on monitors is possible with X, but not
recommended. You're much better off having a single scaling factor for all
monitors. Or switch to Wayland.

We need to set the xrfb font dpi to make other toolkits vaguely usable on high DPI on X.
That's global and there's no way round that. So it's sort of possible, but it breaks more stuff than it fixes.

Is it already supported on Wayland? If yes, we could enable this configuration
only for Wayland users, to provide an incentive to finally ditch X. :)

It will be, see massive patchset on phabricator by me. 
In theory it fixes everything ever.

But I think you've got plenty for a GSOC proposal.
Focus on selecting some apps that don't render at native resolution, you don't want to be trying to take on the whole world.

David