Created attachment 156209 [details] gwenview not filling the screen with an image that should fill the screen See attached screenshot. The Gwenview window is fullscreen, and is displaying a screenshot of my desktop I just took, which has the same resolution as the screen it is shown on. "Fit" doesn't actually fit the window, "Fill" doesn't fill, and "100%" doesn't display it in 100%; all three options display it as shown. The display has 2560x1440 resolution and a scale factor of 125% is configured in systemsettings.
I have been able to reproduce this when using a display scale different from 100% and a screenshot (ensuring the same size as the display) The problem seems to come from DocumentView::toggleZoomToFit and DocumentView::toggleZoomToFill calling "d->setZoom(1., d->cursorPosition());" with "1." zoom, which should probably be a different value (i.e. 1.25 for 125% scale), but I'm unsure as to what's the best way to get the current display scale and apply it to the zoom level instead of a hardcoded "1."
Hi, QWidget has a devicePixelRatioF which contains this 1.25 IIRC: https://doc.qt.io/qt-6/qpaintdevice.html#devicePixelRatioF -- I think that's what you need?
By the way, on my screen on Wayland, 125% wouldn't fit either. I need to set ~160%, which I can't make sense of. The only calculation I can come up with which gives 1.6 would be 1.2 * 1/0.75, but it requires some pretty mixed up maths to get to that starting from "125% scaling". It's plausible though if somebody thought subtracting 1 from the devicePixelRatio and then doing some multiplications was the thing to do.
Using "devicePixelRatio" methods returns "2" in my case, which may be due to using KF5/Qt5 under Wayland. I've tried building with Qt6 but with no luck :-/
You need devicePixelRatioF for sure, devicePixelRatio is only for integer scaling.
Ok, the situation here seems to be that Wayland only supports integer scaling at the moment. My 125% scaling is rounded up to 2, which is what is used by Gwenview to scale the image, which makes it 2 / 1.25 = 1.6 times = 160% too small. Apparently Nate knows about this situation? I will add him to the CC list of this bug. :) But as I understood, there is nothing that can be done right now until either Qt6 or until support for fractional scaling on Wayland (which does exist) is backported to Qt5.
To clarify again, I think there is no problem in Gwenview, its code already accounts for display scaling in abstractimageview.cpp. It just gets the wrong scale from Qt.
Wayland does support fractional scaling, it's just that the result is a bit blurry in Qt 5. In 6, this is better. That shouldn't affect Gwenview though and using devicePixelRatioF() is sane. Feel free to submit a patch!
Hi, I tried this and I think Jorge did too, and both of us get "2.0" from QApplication::devicePixelRatio() with 125% scaling configured in systemsettings. I also tried in Qt6, and I *still* get "2.0". Gwenview as a whole scales fine, but the QGraphicsView code calculating the image size for 100% zoom does not. It ends up with a result that doesn't fill the screen, even though the image has as many pixels as the screen has, because devicePixelRatio() is wrong (or is the "2" correct? I think not). Launching with "-platform xcb" (on Wayland) makes QApplication::devicePixelRatio() return 1.25 as expected, and also makes Gwenview's image scaling work correctly again. I'm running plasmashell 5.26.5 on Manjaro.
*** Bug 466738 has been marked as a duplicate of this bug. ***
FWIW I would provide a patch for this if I could, but I think it's not possible right now. Gwenview wants to 1:1 map image pixels to screen pixels for zoom = 100%. It cannot do that if it gets a surface from the compositor intended for some scale factor, but no correct information about what that scale factor actually is.
Thank you for the bug report. Unfortunately we were not able to get to it yet. Can we ask you to please check if this is still an issue with Gwenview 25.08.0 (the latest released version)?
Hi, the issue got fixed at some point either in kwin or in Qt (or both). It seems to work properly now, at least on my screen. Thanks!