Better compositing timing algorithm
Motivation
The main motivation behind this task is to reduce the latency caused by compositing, particularly make dragged windows lag less behind the cursor, and unlock per screen rendering on Wayland.
Current state
Due to KWin being originally an X11 window manager and compositing manager, the compositing infrastructure is heavily based on Xinerama-style rendering. This means that we have a single compositing timer, if you have several outputs with different refresh rate, the refresh rate will be capped to the lowest one, etc. A typical compositing cycle looks as follows
First of all, you've probably noticed that eglSwapBuffers() and glxSwapBuffers() are called at the next vblank. This is to ensure that we start compositing after a vblank. Second thing is that, in the best scenario, we have a latency of at least one frame. It worked okay-ish on X11, but we need something better...
Proposed design
In order to reduce the latency, the compositor has to perform compositing right before the next vblank, i.e.
With this design, we don't start compositing at a vblank. Instead, we just send frame callbacks. This way, all that precious time after frame callbacks have been sent and before the next compositing cycle starts can be used by clients to submit new buffers.
However, it introduces a new problem - we may miss the next vblank if it takes more than usual amount of time to composite the next frame for various reasons, e.g. the GPU is too loaded up, etc. Our compositing timing algorithm will have to be aware of that and keep the compositing window dynamic to avoid dropping frames.
In order to separate compositing scheduling from the actual act of performing compositing, it's better to introduce a new type whose sole purpose is to pick the best moment to perform compositing. Let's call it RenderLoop. On Wayland, we want every output to have its own render loop, e.g.
Note: VBlanks for outputs with the same refresh rate are not necessarily synchronized
On X11, per screen rendering is not possible with Xinerama, so the most sensible option is to have a single render loop provided by the platform that drives compositing.
Timeframe
We want to get this all done in 5.21.
Testing
With this sort of things, we need a way to visualize when kwin starts compositing. For this purpose, ftrace can be used. I know that d_ed has a WIP patch for that.