| Summary: | Extremely slow UI with some driver/compositor combinations | ||
|---|---|---|---|
| Product: | [Applications] Skanpage | Reporter: | johan.claudebreuninger |
| Component: | general | Assignee: | Alexander Stippich <a.stippich> |
| Status: | CONFIRMED --- | ||
| Severity: | major | CC: | abe.kde.bugs, azcn2503, casta+kde, johan.claudebreuninger |
| Priority: | NOR | ||
| Version First Reported In: | 24.05.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
johan.claudebreuninger
2024-05-08 10:31:21 UTC
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. Does this also happen when using e.g. GNOME's Document Scanner? I am not able to reproduce this with Gnome's document scanner. I experience the same as Adrien using Plasma 6.0.5, Skanpage 24.05.0. For me the issue is when I am using the pixma driver via USB, and happens when I use either X11 or Wayland. Scanning speed is unaffected as previously mentioned. If I use the bjnp:// address of the printer then the UI seems to be very responsive, but then scanning slows down considerably, possibly due to my WiFi. I can report the same issue here. I never take time to report it, but I have the problem since the first time I use skanpage (23.04, 23.08, 24.05). UI is damn slow for every action, but scan speed is not affected. It’s a pain to select a scan zone, or even to save the document. skanlite is NOT affected on the same machine. Setup: - Plasma 5 under X11 (for the oldest versions) - Plasma 6 under X11 or wayland - Scanner : Canon LIDE 400 (PIXMA backend too, USB only) - Computer is a recent intel-based iGPU (i5-12500) Using strace I saw suspicious USBDEVFS_REAPURBNDELAY ioctl loops even while not using the scanner, only browsing the interface. So I check ksanecore and guess what: the bad behaviour is fixed by : https://invent.kde.org/libraries/ksanecore/-/merge_requests/19 The MR speak about *remote* PIXMA scanner, but this bug can be definitively linked, even for local USB PIXMA scanner :) |