*** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY Skanpage has a very slow UI. All integration in the application itself, or in children windows like the file picker, are slow. A click in the UI will usually take a few seconds to execute the action. STEPS TO REPRODUCE 1. Open Skanpage 2. Use Skanpage 3. OBSERVED RESULT The UI of Skanpage is slow regardless of the functionality used. EXPECTED RESULT Fast and reactive as are all other KDE Gear applications. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.9-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 3800X 8-Core Processor Memory: 15.5 Gio of RAM Graphics Processor: AMD Radeon RX 5500 XT Manufacturer: Gigabyte Technology Co., Ltd. Product Name: X570 AORUS PRO System Version: -CF ADDITIONAL INFORMATION
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 :)