https://bugs.kde.org/show_bug.cgi?id=486401
--- Comment #13 from Duncan <[email protected]> --- (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. -- You are receiving this mail because: You are watching all bug changes.
