Bug 373178

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

*** Bug 354533 has been marked as a duplicate of this bug. ***

*** Bug 353910 has been marked as a duplicate of this bug. ***

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

(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

(In reply to Fabian Vogt from comment #5)
> QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS=1 gwenview

works nicely, thanks!

Any update on this one?

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.

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.

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.

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

*** Bug 384114 has been marked as a duplicate of this bug. ***

I started working on a patch, here are the details: https://phabricator.kde.org/D7581?id=18870

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.

*** Bug 370416 has been marked as a duplicate of this bug. ***

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

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.

This bug makes gwenview unusable when display scale is higher than 1.

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

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.

"workaround" is not a solution.
The problem reported here needs a proper fix.

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.

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

Created attachment 112268 [details]
Scaling Factor 1

Created attachment 112269 [details]
Scaling Factor 2

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.

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…

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.

Okular supported HiDPI recently. Maybe Okular and Gwenview's canvas are similar and their solution can be also applied to Gwenview, too.

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

Set scale factor to 1 and only change the font DPI, then ocular should scale fine.

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

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?

Some code to address this has already been sent for review but the author vanished and the code bit-rots now :-(

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

https://phabricator.kde.org/D7581 is the correct direction to fix this ...

*** Bug 402554 has been marked as a duplicate of this bug. ***

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

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

The image view now has HiDPI support. Thumbnail support is coming with https://phabricator.kde.org/D9078

*** Bug 401624 has been marked as a duplicate of this bug. ***

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?

Digikam has a different codebase and will need a different patch.

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