On Thu, Mar 23, 2017 at 5:16 AM, Lukas Hetzenecker <lu...@hetzenecker.me> 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
