Created attachment 137877 [details]
Reproducing the bug

[Just another user happening on this bug in a last-24-hours bugs search.  Clicked it because it said gwenview.  FWIW I don't see the problem here but adding this in case any of it helps.  See below for what I'm running.]

Ouch!  The video makes it quite obvious.

FWIW that looks like classic graphics-accel breakage to me.  X or wayland, and what's your graphics hardware, kernel and mesa versions (and xorg driver if on X), and are you running gwenview on kde/plasma or in a different environment (gnome, xfce...)?  

For troubleshooting if possible can you try with the other of X/wayland and/or with a different desktop environment?  And of course on different hardware if you have multiple machines or a switchable-graphics laptop available to test on.  Does the problem persist?

Does switching the animations radio-button option in gwenview's configuration, imageview tab change the result?  (I'm guessing not since that'd be image-switch animations only and /shouldn't/ affect zooming a single image, but it's worth a try.)

What about (if running a kde/plasma environment with kwin) fooling around with kwin's compositor settings (look under kde/plasma's system settings, display and monitor, compositor)?

Also, you might try things like moving the window offscreen (at least the image part) and back, toggling maximize and back, and/or (with transparency toggled off or 100% opacity) moving another window in front of the gwenview window and away, and see if that forces a redraw.  In my experience forcing refreshes clears such artifacts temporarily but of course moving the image around again creates new artifacts.

As both a test and a workaround you might also try using kwin's zoom effect (system settings, workspace, workspace behavior, desktop effects, accessibility, zoom effect, configure it as you like) instead of doing it in gwenview.  This will work best if your monitor resolution is higher than that of the image so you can just use normal 100% zoom in gwenview, then zoom the entire display using kwin's zoom.  For less than 4k images (on a 4k monitor), 100% gwenview resolution and kwin zooming, with its auto-pan, etc, is actually what I've come to prefer these days (that being one reason I got 4k) as at least on my hardware/drivers it seems to perform better and be less pixelated than over-zooming at the gwenview level.

As I said I don't see the issue here, tho as you can guess from the detail of the above I've had some experience with the problem in the past.  I'm running live-git kde-frameworks/plasma/apps all three (via the gentoo/kde project overlay live-git packages, updated today, gwenview's about says 21.07.70 with frameworks 5.82.0), plasma on wayland on older amd radeon polaris-11 graphics (I never remember the radeon rx-whatever number), current actually live-git kernel (5.12.0-rc8+ ATM) with the amdgpu driver, mesa-21.1.0_rc2, qt-5.15.2.

The problem was when KDE Plasma 5.21.4-1 and Xorg server 1.20.11-1 (125% scaling)
Intel - UHD Graphics 620
Nvidia - GP108BM [GeForce MX250]

- Xorg Intel (125% scaling) - issue!

- Switched to Wayland Intel (100% scaling) - no issue!

- Switched to Xorg Intel (100% scaling) - no issue!

- Switched to Xorg Nvidia (100% scaling) - no issue!

- Switched to Xorg Nvidia (125% scaling) - issue!

- Can't switch to Wayland Nvidia

- Can't switch to 125% scaling on Wayland

As you can see, the problem appears only when 125% scaling is enabled. But I can't use 100% because it is too small for me.

Also, effect disappears when zooming out -> zooming in without moving, but I still don't think this is not a bug

It's definitely a bug, tho I believe it's hardware/drivers dependent.

I /had/ omitted to try with scaling (as you might have guessed seeing as I didn't mention it) as (to my embarrassment) I somehow missed that in your description.  My bad!

But I just tried it now, and at least here, scaling works on wayland. =:^) (Set in kde systemsettings, display and monitor, display configuration. I believe kscreen must be installed, however.  That kcm's missing if it's not.)

And I still didn't get artifacts but performance trying to move the image around was *dramatically* worse/slower, to the point that if that was my otherwise-normal setting I'd definitely be looking for faster alternatives as I'd have trouble working that way.

System scaling with gwenview zooming and image-panning is definitely struggling.  I wonder if amdgpu is set to continue rendering well in that case, or possibly it's kwin-wayland's or mesa's efforts to keep the "every frame perfect, skip frames if necessary" promise that's wayland's normal defined policy, while either X or your hardware makes the other choice and goes for speed over perfect rendering, with those artifacts you're getting the result?

I'm going to have to restart kde/plasma in X mode and test scaling there.  If the results match yours there and it's faster with artifacts on my amdgpu/radeon too we're looking at a rather different bug than if the results match my wayland results and it's slower but still correct on X for me.

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.

Thanks for the detailed answer and testing! I've used kwin before, but it's not as convenient as gwen's scaling because I often switch between windows (.. Hopefully this will be fixed by Gwenview developers, because nomacs I've tried don't have this effect. So I will look for an alternative

I just noticed that this bug shows up even without zoom (100%)

I believe this is actually fixed in version 21.04. Can you please test again once Manjaro packages it?

Ok, I will often check for new versions.

Got a new version (21.04.0).
Intel: nothing changed.
Nvidia: yes! It's disappeared! Almost... breaks only by 1-3 pixels, but still noticeable.

Found other bug report and realized that this bug is a duplicate. (434596)

*** This bug has been marked as a duplicate of bug 434596 ***