Bug 373178 - Blurry scaling on HiDPI
Summary: Blurry scaling on HiDPI
Status: RESOLVED FIXED
Alias: None
Product: gwenview
Classification: Applications
Component: general (show other bugs)
Version: Other (add details in bug description)
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords: usability
: 353910 354533 370416 384114 401624 402554 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-12-02 09:24 UTC by Fabian Vogt
Modified: 2019-04-07 14:02 UTC (History)
30 users (show)

See Also:
Latest Commit:
Version Fixed In: 19.04.0
Sentry Crash Report:


Attachments
Scaling Factor 1 (509.51 KB, image/png)
2018-04-26 15:18 UTC, Adomas Jackevičius
Details
Scaling Factor 2 (512.10 KB, image/png)
2018-04-26 15:18 UTC, Adomas Jackevičius
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Vogt 2016-12-02 09:24:29 UTC
On Gwenview 16.08.3 images shown on a HiDPI (QT_SCALE_FACTOR=2) display are pixelated. Easily reproducible by calling "QT_SCALE_FACTOR=2 gwenview" with an image that has sharp edges.
Comment 1 Andreas Schneider 2016-12-02 09:28:33 UTC
The following commit fixes the UI:

 app/main.cpp | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/app/main.cpp b/app/main.cpp
index 503ea95..97b6a09 100644
--- a/app/main.cpp
+++ b/app/main.cpp
@@ -119,8 +119,11 @@ int main(int argc, char *argv[])
         ));
     aboutData->setShortDescription(i18n("An Image Viewer"));

+    // These attributes must be set before a Q(Gui)Application is constructed.
+    QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
+    QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps);
+
     QApplication app(argc, argv);
-    app.setAttribute(Qt::AA_UseHighDpiPixmaps, true);
     KAboutData::setApplicationData(*aboutData);
     app.setApplicationName(aboutData.data()->componentName());
     app.setApplicationDisplayName(aboutData.data()->displayName());


However this also enables scaling for the images you want to show and that is wrong. They should be showed without any scaling applied.

To test and fix it you can use:

QT_SCALE_FACTOR=2 ./app/gwenview
Comment 2 Jan Kundrát 2016-12-20 10:41:50 UTC
*** Bug 354533 has been marked as a duplicate of this bug. ***
Comment 3 Martin Klapetek 2016-12-22 23:20:03 UTC
*** Bug 353910 has been marked as a duplicate of this bug. ***
Comment 4 cs 2017-01-20 12:32:07 UTC
Recently I got a 27 inch 4k monitor and hoped to look at super crisp and sharp photos so I was really disappointed when I saw that they look pixelated and blurry in my favourite image viewer... This is a showstopper for an image viewing application.

My system: Opensuse Leap 42.2, Plasma 5.8.2, QT 5.6.1
In KDE System settings -> Display and Monitor -> Scale Display the "Screen Scaling" value is set to 1.5

The application is scaled as expected, but the displayed image is scaled, too. Only the UI should be scaled but not the image.

I tried to start Gwenview without any scaling by calling "QT_SCALE_FACTOR=1 gwenview" but this way it appears in exactly the same size as before (with the factor 1.5 compared to the real monitor pixels). Then I called it with QT_SCALE_FACTOR=2 and the UI was really big and the image was still more pixelated, so it seems that the scaling value from system settings and the QT_SCALE_FACTOR environment variable effectively get multiplied. This led me to try calling "QT_SCALE_FACTOR=0.75 gwenview" and now the UI was as big as without any scaling (real monitor pixels), but the image still looked somewhat blurry (I guess it first gets scaled up and then scaled down again or something like that...).

So my questions:

- Does anyone know a way to start gwenview completely unscaled in a scaled plasma environment, ignoring the scaling value set in system settings? This does not solve the problem but would be a first workaround, because the images would look nice and sharp and I don't care much for the UI of Gwenview and could tolerate it being very small.

- Could anyone with QT knowledge please have a look at this problem and tell whether this will be rather easy to fix or impossible at all

Thanks
Comment 5 Fabian Vogt 2017-01-20 12:35:46 UTC
(In reply to cs from comment #4)
> - Does anyone know a way to start gwenview completely unscaled in a scaled
> plasma environment, ignoring the scaling value set in system settings? This
> does not solve the problem but would be a first workaround, because the
> images would look nice and sharp and I don't care much for the UI of
> Gwenview and could tolerate it being very small.

QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS=1 gwenview
Comment 6 cs 2017-01-20 20:52:25 UTC
(In reply to Fabian Vogt from comment #5)
> QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS=1 gwenview

works nicely, thanks!
Comment 7 NW 2017-02-04 14:20:00 UTC
Any update on this one?
Comment 8 LuHe 2017-03-23 10:21:47 UTC
Hello,

just wanted to throw in a link to a discussion happening over at the kde-devel mailing list: https://marc.info/?l=kde-devel&m=149005290016141&w=2

If my Google Summer of Code project is accepted, I want to fix HiDPI scaling bugs like this one in KDE applications. As preparatio, I want to tackle this one.
Comment 9 e.ekmecic 2017-04-21 14:13:09 UTC
I've found that setting XServer DPI manually fixes these fractional scaling problems.
On my 2560x1440 display I use a DPI of 144 (i.e. a scaling factor of 1.5x), which caused problems in regular Qt programs, the lockscreen, shutdown/logout/suspend dialog, Okular etc.

To fix this, added "-dpi 144" to ServerArguments in my sddm.conf and set display scaling back to 1.0x.
This makes KDE and all Qt programs scale flawlessly but GTK programs (i.e. Firefox) remain unscaled which is an acceptable tradeoff for me.

I apologize if I'm spamming the mailing lists as I've been reposting this on all of the bugs I've been tracking related to this issue.
Comment 10 Christoph Feck 2017-04-27 12:29:06 UTC
Unrelated, but at the time I used Firefox I had set some css scaling factor to 1.5 in the about:config. I am now using Otter browser, which has a scaling setting in the settings dialog.
Comment 11 LuHe 2017-05-27 10:56:01 UTC
I'm going to be working on this as part of my Google Summer of Code 2017 project, more details can be found here: https://summerofcode.withgoogle.com/projects/#4835460277862400 and https://drive.google.com/open?id=0BwXqDXwyptm8eEo5bjdZRzZTQkk
Comment 12 Christoph Feck 2017-08-28 19:58:11 UTC
*** Bug 384114 has been marked as a duplicate of this bug. ***
Comment 13 LuHe 2017-08-28 20:02:14 UTC
I started working on a patch, here are the details: https://phabricator.kde.org/D7581?id=18870
Comment 14 younker.dl@gmail.com 2017-10-17 01:19:51 UTC
Just installed my gentoo box and found the issue still there with kde apps 17.08.02. 

From my own point of view, in the viewer of gwenview, no matter it is in the viewer window or fullscreen mode. We should use the pixel to pixel map for rendering images. Discard the screen scale factor.
Comment 15 Nate Graham 2017-10-19 18:56:20 UTC
*** Bug 370416 has been marked as a duplicate of this bug. ***
Comment 16 younker.dl@gmail.com 2017-12-11 13:28:59 UTC
Just wonder to know is the fix will goto 17.12? It has some annoying experience on using gwenview, digikam, etc. when you trying to get pixel to pixel display on the image when you set the SCALE_FACTOR to some value
Comment 17 null 2017-12-11 23:24:05 UTC
The fix won't be in 17.12, the patches are not even ready yet. If you are adventurous, you could compile Gwenview by yourself and apply https://phabricator.kde.org/D7581 and https://phabricator.kde.org/D9078.

Also note that this does not relate to DigiKam at all. Please search for or file a separate bug for that.
Comment 18 Patrick Silva 2018-03-05 11:57:53 UTC
This bug makes gwenview unusable when display scale is higher than 1.
Comment 19 null 2018-03-05 12:03:30 UTC
> This bug makes gwenview unusable when display scale is higher than 1.
No kidding!

On a more serious note: It's helpful to comment on bugs which have been fixed but are not marked as such. Adding "It's still a problem on version X" is not necessary.
Comment 20 Omer Akram 2018-03-05 12:13:42 UTC
Here is a workaround: Just don't change the scaling, keep it to default 1. Change the DPI in fonts settings, everything will scale as it should and you avoid the blurriness.
Comment 21 Patrick Silva 2018-03-05 12:21:58 UTC
"workaround" is not a solution.
The problem reported here needs a proper fix.
Comment 22 Adomas Jackevičius 2018-04-25 19:33:22 UTC
Note: when using custom scaling factor, set by "Display and Monitor -> Displays -> Scale Display", the this issue appears. But when I don't have set custom scaling factor and rely on Qt decision for scaling, this does not appear. By default, when scaling factor is unset, Qt scales my display to ratio of 1.5, and images in Gwenview are sharp and nice. Issue only happens with custom scaling factor.
Comment 23 null 2018-04-25 19:47:57 UTC
> By default, when scaling factor is unset, Qt scales
> my display to ratio of 1.5
Are you sure Qt is scaling something and you are not only seeing an automatic adaptation of the font DPI values? Feel free to share a screenshot.

> and images in Gwenview are sharp and nice. Issue only happens
> with custom scaling factor.
I highly doubt this is the case. Either scaling is enabled (which leads to blur), or not (which works fine). Whether scaling was enabled automatically or manually is not really relevant in that part of the code.
Comment 24 Adomas Jackevičius 2018-04-26 15:18:17 UTC
Created attachment 112268 [details]
Scaling Factor 1
Comment 25 Adomas Jackevičius 2018-04-26 15:18:35 UTC
Created attachment 112269 [details]
Scaling Factor 2
Comment 26 Adomas Jackevičius 2018-04-26 15:23:15 UTC
Hello, Henrik. Here are two screenshots. One screenshot has scaling of 1x and another 2x.

I also use "Force fonts DPI" setting set to 192 (default was 96 I think, so I made it double).

I think Gwenview could ignore Screen scaling factor, like it ignores Fonts DPI on canvas. This way images in Gwenview would be always sharp.
Comment 27 null 2018-04-26 19:05:06 UTC
Thanks for the screenshots, here is what's happening:

You are setting a scale factor in the KScreen KCM, which results in modifying the font DPI as well as setting some environment variables for Qt apps (see https://doc.qt.io/qt-5/highdpi.html).

For Gwenview this means due to the change in DPI you will get larger fonts, and due the other environment variables and "app.setAttribute(Qt::AA_UseHighDpiPixmaps, true);" in main.cpp, Qt will be scaling up everything else, e.g. the border of buttons is doubled in width for 2x scaling. Pixmaps are also scaled by default, but application code can opt out of this behaviour by providing a custom higher resolution pixmap itself. This is done by library code for the toolbar icons, but still missing for Gwenview's image canvas. That's what the Diffs in Comment 17 are about.

As 2x is integer scaling and not fractional scaling (e.g. 1.4x), you'll hardly see any "blurriness". However, what you can see, even in your screenshot, is some sort of blockiness. To demonstrate this, I took your screenshots (note that both are with 100% zoom level set in Gwenview!) and magnified them a bit:

https://phabricator.kde.org/F5823449

You can clearly see that the "pixel" size for the 2x version of the blue image on the bottom is doubled compared to the 1x version above, i.e. it is wrong.

> I think Gwenview could ignore Screen scaling factor
That would be too simple and break the UI. We only need to do some changes for certain pixmaps, see the patch for details.

TL;DR: No, the problem has not been solved magically ;) Let us know if anyone wants to help, because currently the authors of both patches seem to be occupied with other things, so progress is quite slow…
Comment 28 610400210 2018-04-27 20:03:40 UTC
Is this a Qt bug? The canvas was first painted in a low resolution, and it is "frozen" and upscaled in order to show it on screen.
Comment 29 Guo Yunhe 2018-08-14 12:58:58 UTC
Okular supported HiDPI recently. Maybe Okular and Gwenview's canvas are similar and their solution can be also applied to Gwenview, too.
Comment 30 younker.dl@gmail.com 2018-11-12 04:56:10 UTC
(In reply to Henrik Fehlauer from comment #27)
> Thanks for the screenshots, here is what's happening:
> 
> You are setting a scale factor in the KScreen KCM, which results in
> modifying the font DPI as well as setting some environment variables for Qt
> apps (see https://doc.qt.io/qt-5/highdpi.html).
> 
> For Gwenview this means due to the change in DPI you will get larger fonts,
> and due the other environment variables and
> "app.setAttribute(Qt::AA_UseHighDpiPixmaps, true);" in main.cpp, Qt will be
> scaling up everything else, e.g. the border of buttons is doubled in width
> for 2x scaling. Pixmaps are also scaled by default, but application code can
> opt out of this behaviour by providing a custom higher resolution pixmap
> itself. This is done by library code for the toolbar icons, but still
> missing for Gwenview's image canvas. That's what the Diffs in Comment 17 are
> about.
> 
> As 2x is integer scaling and not fractional scaling (e.g. 1.4x), you'll
> hardly see any "blurriness". However, what you can see, even in your
> screenshot, is some sort of blockiness. To demonstrate this, I took your
> screenshots (note that both are with 100% zoom level set in Gwenview!) and
> magnified them a bit:
> 
> https://phabricator.kde.org/F5823449
> 
> You can clearly see that the "pixel" size for the 2x version of the blue
> image on the bottom is doubled compared to the 1x version above, i.e. it is
> wrong.
> 
> > I think Gwenview could ignore Screen scaling factor
> That would be too simple and break the UI. We only need to do some changes
> for certain pixmaps, see the patch for details.
> 
> TL;DR: No, the problem has not been solved magically ;) Let us know if
> anyone wants to help, because currently the authors of both patches seem to
> be occupied with other things, so progress is quite slow…

Just wonder on the progress of this one. As an image viewer application, showing the image correctly on hidpi display is the basic functions. I known AlienSkin software use QT, and it doesn't have such issues on both Windows and Mac, I believe we should also fix this for Gwenview and Digikam as what we need to do is to ignore the scale factors for displying the image.
Comment 31 Omer Akram 2018-11-12 07:06:16 UTC
Set scale factor to 1 and only change the font DPI, then ocular should scale fine.
Comment 32 younker.dl@gmail.com 2018-11-12 13:22:26 UTC
(In reply to Omer Akram from comment #31)
> Set scale factor to 1 and only change the font DPI, then ocular should scale
> fine.

I don't think this is the right solution. With this settings, many applications' icon and other UI element will not display right, especially for icons shown in toolbar, tab page, or other dialog part. 

So this does need a solution to fix the image display no matter the scale factor that user set.
Comment 33 younker.dl@gmail.com 2018-11-23 00:28:20 UTC
after changing to a 27" 4K display, I found the bluring is even worse than it on the 24" 4K display. 

Just wonder to know is there any plan to fix it with the right scale factor?
Comment 34 Andreas Schneider 2018-11-23 07:07:24 UTC
Some code to address this has already been sent for review but the author vanished and the code bit-rots now :-(
Comment 35 tildearrow 2018-11-30 16:38:46 UTC
But didn't you write a patch to fix the issue ~2 years ago? Why not send that for review instead?

(or maintain and send the abandoned code?)
Comment 36 Andreas Schneider 2018-11-30 17:01:48 UTC
https://phabricator.kde.org/D7581 is the correct direction to fix this ...
Comment 37 Christoph Feck 2018-12-25 14:34:02 UTC
*** Bug 402554 has been marked as a duplicate of this bug. ***
Comment 38 younker.dl@gmail.com 2019-03-13 12:23:05 UTC
It's now 2019, and the issue still was not fixed yet for gwenview and digikam. Good thing is I found another one named qimgv which act right. So just use that for a temporary solution for viewing my photos.
Comment 39 Patrick Silva 2019-03-13 18:11:52 UTC
Thank you so much for mentioning qimgv.
I was using PhotoQt, but qimgv seems better.(In reply to younker.dl@gmail.com from comment #38)
> It's now 2019, and the issue still was not fixed yet for gwenview and
> digikam. Good thing is I found another one named qimgv which act right. So
> just use that for a temporary solution for viewing my photos.

Thank you so much for mentioning qimgv.
I was using PhotoQt, but qimgv seems better.
Comment 40 Alexander Volkov 2019-04-04 14:41:53 UTC
Git commit 97e7de52276b46bc99b64117abfee0965e6f58e6 by Alexander Volkov.
Committed on 04/04/2019 at 14:40.
Pushed by volkov into branch 'Applications/19.04'.

HiDPI Support for Gwenview

Summary:
Initial support for HiDPI-scaling of documents in RasterImageView.

This patch scales up images to display them correctly on HiDPI-enabled screens.

TODO:
- SVG documents and videos
- Scaling of thumbnails

Reviewers: davidedmundson, rkflx, hetzenecker, ngraham, #gwenview

Reviewed By: ngraham, #gwenview

Subscribers: volkov, asturmlechner, fvogt, abalaji, rkflx, ngraham, anthonyfieroni, cfeck, asn

Tags: #gwenview

Differential Revision: https://phabricator.kde.org/D7581

M  +24   -12   lib/documentview/abstractimageview.cpp
M  +12   -0    lib/documentview/abstractimageview.h
M  +2    -2    lib/documentview/birdeyeview.cpp
M  +5    -1    lib/documentview/documentview.cpp
M  +11   -4    lib/documentview/rasterimageview.cpp
M  +38   -22   lib/imagescaler.cpp

https://commits.kde.org/gwenview/97e7de52276b46bc99b64117abfee0965e6f58e6
Comment 41 Nate Graham 2019-04-04 16:01:02 UTC
The image view now has HiDPI support. Thumbnail support is coming with https://phabricator.kde.org/D9078
Comment 42 Nate Graham 2019-04-04 16:10:58 UTC
*** Bug 401624 has been marked as a duplicate of this bug. ***
Comment 43 younker.dl@gmail.com 2019-04-05 00:55:54 UTC
Happy to see there is a fix for viewer in 19.04, will try to get sometime to test these patches on my gentoobox first. Btw, will the same patch applied to gigikam?
Comment 44 Nate Graham 2019-04-05 04:26:26 UTC
Digikam has a different codebase and will need a different patch.
Comment 45 Nate Graham 2019-04-07 14:02:47 UTC
Git commit 968c411a99576aa9e7784812e26e054ab290ae27 by Nate Graham, on behalf of Alexander Volkov.
Committed on 07/04/2019 at 14:02.
Pushed by ngraham into branch 'Applications/19.04'.

Add HiDPI support for thumbnails

Summary:
The idea is to localize changes in ThumbnailView as much as possible:
ThumbnailView::thumbnailSize() returns the size in device independent
pixels, i.e. it seems from the outside that ThumbnailView behaves as
well as before this change. But, of course, item delegates must take
into account that ThumbnailView::thumbnailForIndex() will return
a pixmap with the devicePixelRatio set.

Reviewers: #gwenview, ngraham

Reviewed By: #gwenview, ngraham

Subscribers: ngraham

Tags: #gwenview

Differential Revision: https://phabricator.kde.org/D20267

M  +11   -7    lib/thumbnailview/previewitemdelegate.cpp
M  +10   -7    lib/thumbnailview/thumbnailbarview.cpp
M  +1    -1    lib/thumbnailview/thumbnailslider.cpp
M  +16   -10   lib/thumbnailview/thumbnailview.cpp

https://commits.kde.org/gwenview/968c411a99576aa9e7784812e26e054ab290ae27