https://bugs.kde.org/show_bug.cgi?id=436136
Duncan <1i5t5.dun...@cox.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |1i5t5.dun...@cox.net
--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
[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.
--
You are receiving this mail because:
You are watching all bug changes.
