Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • KWin KWin
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 55
    • Issues 55
    • List
    • Boards
    • Service Desk
    • Milestones
  • Bugzilla
    • Bugzilla
  • Merge requests 150
    • Merge requests 150
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • PlasmaPlasma
  • KWinKWin
  • Issues
  • #22
Closed
Open
Issue created Nov 04, 2020 by Vlad Zahorodnii@vladzDeveloper

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

before

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.

ideal

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.

per-screen-rendering

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.

Edited Nov 04, 2020 by Vlad Zahorodnii
Assignee
Assign to
Time tracking