https://bugs.kde.org/show_bug.cgi?id=486771
Adrien Beau <abe.kde.b...@zerty.xyz> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |CONFIRMED
CC| |abe.kde.b...@zerty.xyz
Ever confirmed|0 |1
Version|24.02.2 |24.05.0
Summary|Skanpage slow UI |Extremely slow UI with some
| |driver/compositor
| |combinations
--- Comment #1 from Adrien Beau <abe.kde.b...@zerty.xyz> ---
The initial bug report does not convey how terribly slow Skanpage UI can
become in some cases. This is not "it would be nice if it was a bit
smoother", but rather "something is badly broken here".
We're talking UI delays that can be measured in *seconds*. More than one
second after a key press before the text appears in the text field. More
than one second after the mouse hovers over a button before the button
changes its state to show it is being hovered. Several seconds after a
click before a window pops-up. After selecting the scanner, Skanpage
does some kind of animation to put the side panels in place. We can see
the very distinct single steps of that animation.
It feels as if the machine is down to its knees due to heavy load.
However the rest of the machine is fine, only Skanpage is affected,
something is killing its UI event loop. The rest of Skanpage seems to
still work fine, notably scan speed is unaffected.
This only happens in some circumstances. Having two computers and two
drivers for the scanner, there's only one of the four combinations that
triggers the issue.
Computer A: recent high-end desktop, NVIDIA GPU, running X11
Computer B: old mid-tier NUC, Intel iGPU, running Wayland
Both running the latest KDE neon with the same settings apart from the
compositor.
Computer A + airscan driver: works fine
Computer A + pixma driver: works fine
Computer B + airscan driver: works fine
Computer B + pixma driver: terribly slow!
This issue is present in Skanpage 24.02.2 and 24.05.0.
--
You are receiving this mail because:
You are watching all bug changes.
