Created attachment 169072 [details] Video of bug *** 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 *** Lagging/Slow scrolling STEPS TO REPRODUCE 1. Open KDiff3 and do any diff of two files 2. Scroll using the scroll wheel of your mouse 3. OBSERVED RESULT Lagging/slow scrolling EXPECTED RESULT Smooth scrolling SOFTWARE/OS VERSIONS KDE Frameworks Version 6.1.0 Qt Version 6.7.0 (built against 6.7.0) The wayland windowing system ADDITIONAL INFORMATION
I can reproduce a rubberband effect under Wayland, when run as X application it instead just drops the frames. Wonder if that is an issue with kdiff’s painting. Fwiw I made a patch for Qt Wayland to implement backingstore scrolling, so it only has to repaint a small region as you scroll, which should improve performance (when not using fractional scaling) albeit not entirely: https://codereview.qt-project.org/c/qt/qtwayland/+/528803
[CCing after having seen the bug mentioned on the kde-core-devel list, which I follow via gmane.io's list2news service.] Confirming here too. gentoo kdiff3 1.11.4 qt 6.7.2 frameworks live-git (using the gentoo/kde overlay ebuilds) updated Sep 18, reports 6.7.0 plasma live-git desktop, wayland by default, plasmashell reports 6.1.90 I ran kdiff3 with --platform xcb to run in xwayland for the X side test. I'm on decade-old hardware, amdgpu graphics. The scrolling lag was there on wayland but not /horrible/. I ran kdiff3 wayland-native first (it was a fresh build/install so was testing that it'd even run, too) and honestly didn't notice a lag -- I suppose I was subconsciously attributing it to a scrolling animation effect. Only after running it under xwayland and seeing the faster scrolling there did I really notice the wayland-native scroll-lag. Then I ran two windows, one wayland-native one xwayland, flipping between them and scrolling, and the wayland-native scrolling lag became /quite/ obvious. So now CCing and we'll see where this goes. I might try that qtwayland patch if I get time.
Hi, still present in version 1.12.0, Qt 6.7.2, KF 6.10.0, Wayland on Debian Trixie. The delay is severe, making scrolling with the scrollbar on longer diffs unusable. Best regards, Andrej
Git commit a02232819213714e43b36943e4899ad5b9000c34 by Michael Reeves. Committed on 17/02/2025 at 14:10. Pushed by mreeves into branch '1.12'. Back port EncodedDataStream re-write. This provides a major speed up for file loading for large files. It also seems to impact Wayland spciefic scrolling delays (Bug: 486401) . A +290 -0 src/EncodedData.h [License: GPL(v2.0+)] D +0 -133 src/EncodedDataStream.h M +10 -7 src/MergeEditLine.cpp M +2 -1 src/MergeEditLine.h M +18 -22 src/SourceData.cpp M +37 -68 src/mergeresultwindow.cpp M +0 -3 src/mergeresultwindow.h https://invent.kde.org/sdk/kdiff3/-/commit/a02232819213714e43b36943e4899ad5b9000c34
For some reason this issue no longer repros on my test machine. I back ported a file load optimization from master that may have impacted this but I still don't know what the true root cause is.
Hi, thank you for your patch, but for me it didn't seem to work. I used the trixie package (1.12.0) as base (https://packages.debian.org/trixie/kdiff3), applied the patch and rebuild. No change to laggines in both virtualbox and live system. I used HTML source of https://kde.org in two different languages. I'm however a newbie when it comes to building packages, so it would be great if other commenters could also test this. Best regards, Andrej
Is someone able to see call-grind out put from the scrolling? It might help to see where the delay is.
Created attachment 178702 [details] Callgrind profile I'm attaching the callgrind profile which was created with invoking: valgrind --tool=callgrind kdiff3 test1.txt test2.txt Both files had approx 450 short lines. After the gui was opened, I dragged the scrollbar and closed the program when it stopped scrolling.
Thanks. I use arch myself but kiff3 installed from the current stable branch in Debug configuration. Originally I did see it in 1.11.x.
I've generated a graph from that callgrind output, it looks like most of the time is spend in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag> 91.72%
That's the base start call for any application in Qt so it always shows up. Further down we see QTextLayout::draw being called. This function has a high call count and is most likely the source of the holdup. This is also the point where we have our first stack traces from kdiff3's code. At the very least that points to a code area in which even a small change in speed can add up quickly. I used this same technique to find the file load hold up. The actual symbols for kdiff3 itself are miss but there only two places this is called.