https://bugs.kde.org/show_bug.cgi?id=373178
--- Comment #27 from Henrik Fehlauer <rk...@lab12.net> --- 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… -- You are receiving this mail because: You are watching all bug changes.
