https://bugs.kde.org/show_bug.cgi?id=436136
--- Comment #5 from Duncan <1i5t5.dun...@cox.net> --- Here's my X mode results, first some generic X/wayland scaling differences I discovered before I get into the gwenview-specific behavior: Scaling on X works a bit differently than it does on wayland. I've two monitors and on (kwin-)wayland scaling is per-monitor while on X it's global. And on X I have to restart the plasma session (which FWIW I do from a CLI login, no graphical display-manager login installed, so quitting a session quits to the CLI login from which I can run a new session) to have the new scaling settings take effect, while on wayland they take effect immediately. Also, on wayland it's possible to scale below 100%, effectively giving you more screen space for more windows at the cost of a smaller UI, if you can read it. On X the minimum is 100%, no way to "scale out" below that (tho on pure X it's possible to set an arbitrarily large X framebuffer and configure panning within it for a similar effect, but at least some years ago when I tried that with kde, it apparently reset the framebuffer to the bounding rectangle of the screens). And I'm not exactly sure of the technical details from the quick tests and don't want to spend more time back in X than I have to (at one point kwin-wayland wouldn't run due to a live-git bug between releases, and I was stuck on X only for a week or two! hey, at least X ran!), but best I could describe it, on X, "different things scale" than on wayland. I /think/ it's the UI that scales on wayland, while on X it's everything. So on wayland the buttons and text scale but for instance the image in gwenview, when set to 100%, is the same size (the same number of absolute screen pixels, 1:1 matched at 100%) either way. But I'd have to spend more time comparing them and perhaps reading some documentation to be sure. Of course you can always zoom either/both the whole display using kwin, or the gwenview zoom-factor and the gwenview zoom's what this bug is about, so... Confirming my suspicions on X moving the zoomed image around in 125% scaling mode was *much* faster than on wayland, near the speed of 100% tho I restarted kde-X a couple times at both 100 and higher scalefactors to better compare, and there was still /some/ scaling slowdown dragging the zoomed image around. And yes, I did see the block-artifacting on 125% scaled X, tho I was testing with a normal photo-image so it wasn't as noticeable as it was with the line-drawing in your video. Dragging back and forth as fast as I could actually left a detectable "smeared" image at one point, where the visible edge was obviously repeatedly redrawn, creating the smear-effect. Of course I tried it at 100% scale also, to compare. Try as I might I couldn't get that to artifact, so the result there was similar to on wayland. But I /did/ notice some "screen-tear" from redraw in the middle of a buffer-fill, something that's supposed to be difficult to avoid on X, while on wayland they use page-flipping and continue redrawing the old page until the app says the new one is ready. That reminded me that the xf86-video-amdgpu driver has a tearfree option, so I checked on it, and it was set to "auto", which is off at normal rotation and xrandr translation matrix, on if rotated or a non-identity xrandr translation matrix is applied. So I turned it on to see if that made a difference, of course restarting the kde session again in both 125% and 100% scaled modes. While turning the amdgpu tearfree on /did/ appear to eliminate the screen-tearing it didn't noticeably affect gwenview's zoomed-drag performance. But my "monitors" are actually TVs limited to 60 Hz refresh. If they were able to do 120 Hz @ the native 4k resolution the tearfree may have had a worse performance impact. Conclusion: X's graphics seem to be tuned for performance at the cost of artifacting if the gpu can't keep up, as seems to be the case for both of us with scaling. That's across graphics drivers and hardware. On wayland we only have my results as your drivers apparently don't have scaling enabled on wayland yet, but at least with my aging amd radeon rx460 graphics (I checked xorg.log for the tearfree setting and noticed the rx number there) wayland appears to go for quality over speed and scaling seems to make it work hard enough to really slow things down, but without the artifacting we both see on scaled-X. But I'd still urge you to try enabling and configuring the kwin zoom effect, setting up hotkeys so you can zoom in and out relatively easily. Then try leaving gwenview at 100% zoom so you don't have to deal with the artifacting there, and see if kwin's full-display zoom effect doesn't avoid the artifacting. Actually, I'd suggest trying 100% scaling and just using the kwin zoom effect for that as well. Among other things that gives you a bigger workspace that you can pan around, with return to "actual size" possible when you need "the big picture" after which you can zoom back in if desired. YMMV as they say, but given a bit of time to adjust to the change and with a bit of luck hardware and driver-wise, you'll find the performance at least as good and the quality arguably better than scaling. Certainly that has been my experience tho again YMMV. But it's definitely worth a try and hopefully it'll be a useful and more-performant/less-artifacted workaround. Meanwhile, this bug remains. Your video was a great demonstration of its nasty effects! Hopefully it gets fixed so it doesn't have to bother others, regardless of whether you find the kwin-effect-zoom workaround actually useful for you, or not. -- You are receiving this mail because: You are watching all bug changes.
