Currently kwin_wayland does almost all tasks synchronously in the main thread, which is an issue in term of performances especially when kwin loads things such as effects at runtime, or interacts with clients that give heavy tasks to the compositor. As a Plamsa-Wayland user, I see to many scenario where kwin drop frames, including the mouse cursor even if hardware cursor is enabled. It’s very noticeable on a high refresh rate monitor.
Examples of freezes:
- Alt-tabbing is causing micro-freezes, because
kwinis stall during the load of the animation effect. https://bugs.kde.org/show_bug.cgi?id=479250. - Applications such as Gimp which set the cursor shape every frame can slowdown
kwinand causes frame drops at high refresh rate. https://bugs.kde.org/show_bug.cgi?id=506240. - Applications which are not GPU accelerated slowdown
kwinbecause the framebuffer is copied from CPU to GPU synchronously in the main thread of the compositor. https://bugs.kde.org/show_bug.cgi?id=513295.
These performance issues happens only in a Wayland sessions. With Xorg, a least the cursor is always smooth.
Here is a proposal of the thread architecture:
- A dedicated thread for input management and cursor position.
- A dedicated thread for the
kwinrender. - A thread pool to manage threads for applications interactions, effects and other heavy tasks.
- A KMS thread (already implemented).
- A dedicated thread for window management.
- The main thread should only be used for
kwininitialization/termination and thread management.
I know all of that is hard to implement and can’t be implemented straight away, but this is just to give an idea to how I see performance issues in kwin_wayland and I hope my advice will help KDE developers to improve kwin which is an incredible project.