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.

(In reply to Duncan from comment #2)
> I ran kdiff3 with --platform xcb to run in xwayland for the X side test.

I had to remove `Wayland windowing system` permission in the Flatpak build. It's a huge improvement, thanks!

Operating System: Fedora Linux 43
KDE Plasma Version: 6.5.1
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.5-300.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 7950X3D 16-Core Processor
Memory: 64 GiB of RAM (62,4 GiB usable)
Graphics Processor: AMD Radeon RX 7900 XTX

(In reply to madness742 from comment #12)
> (In reply to Duncan from comment #2)
> > I ran kdiff3 with --platform xcb to run in xwayland for the X side test.
> 
> I had to remove `Wayland windowing system` permission in the Flatpak build.
> It's a huge improvement, thanks!

No flatpack here but at an educated guess removing the wayland windowing system permission forces X mode (so xwayland while in a native wayland session, similar to --platform xcb in my tests), which by reports does not suffer the apparently wayland-native-only scrolling slowdown.

So that would seem to be a reasonable workaround, indeed. =:^)

Question: Is the wayland windowing system permission settable at flatpack runtime or must it be set in the flatpack at build or flatpack assembly time?

Particularly if the latter, but as a sane bug-bypass default regardless, it could be worthwhile to force the flatpack into X mode by default (that is, in the distributed flatpack) until this bug is resolved.  Presumably that could be via no wayland windowing permission as you did, or via commandline --platform xcb inside the flatpack as I did for my native-run testing.

(In reply to michael from comment #11)
> [In callgrind] 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.

So I don't claim to be a dev but routinely run live-git of various packages and have been involved on a number of wayland porting bugs.

One we ran into with (gtk-based) claws-mail traced down to a frequently invoked  "live" drawing call.  Turns out that while X works fine with making such calls from all sorts of contexts because it allows screen-tearing and thus writes directly into the rendering buffer from anytime/anywhere, wayland's every-frame-perfect-by-default (no screen-tearing) strategy doesn't work well in the same context because effectively every "live" drawing call forces a wayland frame update (well, on gtk, I'm aware qt/kde could be different, but this bug suggests not in this case anyway...), thus syncing the call rate to the frame-rate.

The fix there was to replace all those "live" draw calls with draw-delayed calls, basically noting the "damage" at every draw-delay ed invoke but leaving the actual "live" draw call to be invoked only once in the usual frame-update refresh loop.  IIRC in that case it helped with not only drawing performance but also fixed a couple other drawing related bugs (missing visual elements because an update to one thing got overwritten by another call from elsewhere a frame later... tho I think those were related to the gtk2>gtk3 update basically happening in parallel, thus why they hadn't occurred in the X-only gtk2 version previously) as well.

Given the similar wayland-only laggy symptoms and noted high-frequency draw call, an educated if non-dev guess suggests a similar solution to the similar problem, there on gtk, here on kde/qt.

I could additionally suggest talking to the konsole folks, as from the git logs they've had to deal with similar laggy wayland scroll updates (of course terminals have more to lose/gain in the scrolling efficiency game than pretty much anyone), and they'd surely have more appropriate kde/qt experience.  But I only know that from the git logs and don't have the direct bug and fix knowledge I did of the claws-mail thing, so I described the one I had more direct knowledge of.

(In reply to Duncan from comment #13)
> Question: Is the wayland windowing system permission settable at flatpack
> runtime or must it be set in the flatpack at build or flatpack assembly time?
The changes must go in the manifest, which can be found here: https://github.com/flathub/org.kde.kdiff3/blob/master/org.kde.kdiff3.json.

> or via commandline
> --platform xcb inside the flatpack as I did for my native-run testing.
When the `Wayland windowing system` permission is granted, `--platform xcb` parameter, gives me the following error:

```
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-egl, wayland, xcb.
```