SUMMARY Starting Element, the semi-official Matrix client, seems to cause a full stop on compositing the desktop for a short while. Both the mouse pointer and unrelated window contents will freeze for a few seconds. Now my ThinkPad is ~5 years old and I'm running debug builds of everything, so it's possible that a regular user will experience a shorter interruption. Still, starting a program should not cause frame skips in other programs, let along drag down the desktop for a prolonged amount of time. STEPS TO REPRODUCE 1. Load an infinite CSS animation in your favorite browser, e.g.: https://codepen.io/ykadosh/pen/XWBKjEV 2. Start Element. (On my system, this will still reproduce on repeated app starts.) 3. Keep moving the pointer moving until Element's main window appears. OBSERVED RESULT While starting the app, both the CSS animation and the mouse cursor will freeze until the window appears. EXPECTED RESULT No freezes ever. SOFTWARE/OS VERSIONS Element version: 1.11.90 Crypto version: Rust SDK 0.8.0 (21f7cc7), Vodozemac 0.8.1 KWin version: bea7cdac8f24b0320becb53edb9078fd35cb2128 (master branch from Feb 1, 2025, close to the 6.3.0 release date) Operating System: Arch Linux KDE Plasma Version: 6.3.80 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.1 Kernel Version: 6.12.10-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz Memory: 15.3 GiB of RAM Graphics Processor: Intel® UHD Graphics 620 Manufacturer: LENOVO Product Name: 20QD001VUS System Version: ThinkPad X1 Carbon 7th ADDITIONAL INFORMATION Debug build of kwin, Plasma Desktop/workspace and dependencies, KF6, but not Qt which comes from standard (release -build) Arch packages. Regular KDE software such as Kate or Konsole, or even non-KDE software such as Webcord (using Electron), seem to cause no noticeable freezes on startup. I've really only seen Element do this to KWin so far.
I see no stutter or hang when opening element. If you can ssh in from a second device, could you get the backtrace from where KWin is stuck (if it is stuck in any specific place)?
Created attachment 178673 [details] Stuttering kwin_wayland trace 1 (default sample rate, no initial screen activity) So I haven't set up my sshd yet and wasn't confident that I'd hit the enter key at the right time for the right breakpoint. I decided to learn about perf instead. Here are a few for the kwin_wayland process, captured with perf record and converted to Firefox Profiler format with: > element-desktop & > sudo perf record -g -p <pid of kwin_wayland> > # click on Konsole window to refocus it, then Ctrl+C to stop recording > sudo chown kpetso:kpetso perf.data > perf script report gecko > # open https://profiler.firefox.com/ to load gecko_profile.json This first profile was fairly well timed, the stutter occurring shortly after the perf invocation. I didn't move the mouse or have animations on at first, so there's no activity on the kwin_wayland thread before the block. Once I figured out how to get a good view into the profile (i.e. with Firefox), it's pretty obvious what's going on. My other profiles also confirm this. Through some timer signal/slot, the main thread calls GlobalShortcutsRegistry::refreshServices(), which in turn asks for a KService::serviceByStorageId(), which calls KSycoca::ensureCacheValid() and for some reason the cache has to be recreated. Being KSycoca, that takes a little while and until it's done, it blocks on a lockfile. This blocking is my stutter.
Created attachment 178674 [details] Stuttering kwin_wayland trace 2 (5700 Hz sample rate, no initial screen activity) Here's a similar profile, except recorded with -F 5700, which is the maximum it lets me do.
Created attachment 178675 [details] Stuttering kwin_wayland trace 3 (5700 Hz sample rate, always moving mouse pointer) For this one, I thought wouldn't it be nice if I kept moving the mouse all throughout so the pause is clearly visible? So this profile is perhaps the clearest insight. Toward the end there are brief input breaks prior to stopping my perf invocation, but the big pause at the beginning is extremely visible and with just the same stacktrace. I could probably take another profile that shows system-wide loads, but this is what I've got right now, it looks actionable enough to act on. Let me know if you need anything else in particular.
Created attachment 178678 [details] Stuttering kwin_wayland trace 4 (5700 Hz sample rate, system-wide) Alright, I took another few profiles system-wide, showing all processes. Uploading the clearest one. In this profile, ksycoca6 shows up prominently (twice!) while kwin_wayland only gets more samples later in the recording. I'm not quite sure why it doesn't continue working sooner after ksycoca6 is finished, but once it does, it's still finishing up GlobalShortcutsRegistry::refreshServices(). Interestingly, plasmashell is also doing a bunch of work shortly afterwards, focused on KAStatsFavoritesModel and AppEntry::reload(). That's probably related to my Element icon in the panel's favorites list, so it can temporarily remove it and make an task entry (traditional Icons-and-Text panel). In another system-wide trace, I saw plasmashell write the new sycoca instead of a dedicated kbuildsycoca6 process. I guess the KBuildSycoca class isn't picky which process does the work.