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 58
    • Issues 58
    • List
    • Boards
    • Service Desk
    • Milestones
  • Bugzilla
    • Bugzilla
  • Merge requests 160
    • Merge requests 160
  • 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
  • Merge requests
  • !507

Rework compositing scheduling

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Vlad Zahorodnii requested to merge work/compositing-timing into master Dec 01, 2020
  • Overview 109
  • Commits 16
  • Pipelines 0
  • Changes 92

At the moment, we want to perform compositing immediately after a vblank. The problem with doing so is that it introduces latency. Ideally, the compositor, like a ninja, has to wake up close to the next vblank event, perform a compositing cycle and continue sleeping. This way applications can present their contents with low latency. Another problem is that true per screen rendering is not possible with current frame scheduling mechanism.

This patch set addresses those two problems by introducing a new type that it responsible for scheduling compositing - RenderLoop. On Wayland, every output has a RenderLoop. On X11, the RenderLoop is exposed via the platform.

The RenderLoop tries to minimize the latency by scheduling compositing as close as possible to the next vblank . However, there is no any "silver bullet" algorithm for scheduling repaints, some trade-offs have to be made, unfortunately. Specifically, we have to choose between "latency" and "stable animations." Given that we cannot make such decisions for users, a new option has been introduced to set the desired latency level. By default, it's "Medium", but users may increase it to get more stable animations or decrease it to reduce the latency.

The scheduling algorithm makes two estimates about the expected render time:

  • The first estimate is solely based on the user configured latency level. Higher latency levels result in bigger estimated render times, and lower latency levels result in smaller render times
  • The second estimate is based on the previous render times

The estimate that has larger render time is used for arming the compositing timer. We make two estimates to stabilize the frame rate.

With the proposed design, animations are advanced to the next expected presentation timestamp. In other words, effects animate windows a little bit ahead of time.

This is still a work in progress. Due to the scale of this merge request, I plan to create a couple of sub-merge requests. Since it's a WIP, some things in the MR are still subject to change.

I run kwin/wayland with this patch on my daily driver machine, and it seems to work fine, but still, bugs are expected.

closes #22 (closed) cc #24

Edited Dec 14, 2020 by Vlad Zahorodnii
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: work/compositing-timing