Rework compositing pipeline
Open, HighPublic

Description

The Compositor class needs an overhaul. Here is a crude overall plan.

Preliminary cleanup

D21654 D21655
D22218 D22220
D22225 D22270
D22277 D22278
D22295

Structure

  • Split up Compositor class into X and Wayland subclasses. D22195 D23011 D23032
    • All the timers for starting and deleting unused effects properties can likely go into the X child class only. It's only relevant when Compositor selection is given up and reclaimed on X. [1][2]. There is one special case though also on Wayland: when a Gl error is detected in theory the Scene could request a reinit of the Compositor.
  • Introduce Frame objects encapsulating single frames, each created at beginning of compositing run and destroyed again on next page-flip.

Features

  • Listen for vblank events via GLX_OML_sync_control and DRM page flips.
    • Fall back to timer when not available (When it's not? Framebuffer?).
    • Some effects have internal timers and require KWin to not block. Keep that possible. Same holds of course for input on Wayland, but this is already threaded.
  • Compositing per AbstractOutput (i.e. crtc) if possible on Wayland and X, or if not only on Wayland.
  • One thread per output T5710

Scene integration

We already can paint per screen. Maybe this is already sufficient.

Platform integration

With AbstractOutput.

[1] https://git.reviewboard.kde.org/r/106844/
[2] https://git.reviewboard.kde.org/r/110232

Related Objects

romangg created this task.Jun 11 2019, 9:35 AM
romangg triaged this task as High priority.
romangg moved this task from Backlog to Work In Progress on the KWin board.
zzag added a subscriber: zzag.Jun 11 2019, 11:04 AM

One thread per output

Is it possible though? It would be nice, but kwin is synchronous up to the teeth.

In T11071#187996, @zzag wrote:

One thread per output

Is it possible though? It would be nice, but kwin is synchronous up to the teeth.

Don't know yet. Needs some investigation for sure. The DRM page flip events at least come in asynchronously. In Scene::paint we currently iterate in a for-loop over all outputs (if our backend supports per-output presenting), so what happens in this for-loop seems independent of each other. There are some setup tasks done before and after though which might be dependent.

In regards to Effects: I hope these are not coupled with the frame-rate and presenting a final image with them can be done without state change. I assume you have some insight into that?

zzag added a comment.EditedJun 11 2019, 11:17 AM

Well, sort of... Pretty much all effects update their state in prePaintScreen method. By the way, this may lead to a problem (with the proposed compositing pipeline): if an effect animates a window that "is" on two screens, it's quite possible to see a seam.

cfeck added a subscriber: cfeck.Jun 12 2019, 9:54 AM
romangg updated the task description. (Show Details)Jul 2 2019, 1:05 PM
romangg updated the task description. (Show Details)Jul 2 2019, 9:26 PM
romangg updated the task description. (Show Details)
cfeck added a comment.Jul 3 2019, 7:48 PM

You are already my hero of this month ;)

You are already my hero of this month ;)

Thank you Christoph, that's very nice of you to say. I will try to not become a villain by introducing too many regressions. :)

romangg updated the task description. (Show Details)Jul 8 2019, 11:37 AM
ognarb added a subscriber: ognarb.Aug 8 2019, 3:01 PM
baberts added a subscriber: baberts.

I was just made aware of your work here by the developer of kwin-lowlatency, and i gotta say, I'm quite in love with the idea! Kwin really needs some love! Good luck!