Rework compositing pipeline
Closed, WontfixPublic

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 GLX_INTEL_swap_event and DRM page flips.
    • GLX_OML_sync_control does not provide events but vsync and frame timing control. Since we as compositor are better served by repainting whenever damage is done by one of our clients it is not directly needed. But we might optimize by using it to approximate the next vblank time and sending the frame shortly before that (instead of using the average frame time).
  • Fall back to timer when not available (When it's not? See D23105#511957 for on which hardware which extension is available and D23881 for Nvidia solution).
  • 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.
    • With most of relevant reworking patches landed now get feedback asap.
  • Compositing per AbstractOutput (i.e. crtc) if possible on Wayland and X, or if not only on Wayland. --> follow up task T5710
  • One thread per output, this is not so good because there is a single scene spanning all outputs. What could be an idea is to put the rendering pipeline overall into a separate thread. But this needs to go into a follow-up task

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

StatusAssignedTask
Wontfixromangg
OpenNone
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!

romangg updated the task description. (Show Details)Nov 14 2019, 9:00 AM
dcahal added a subscriber: dcahal.Jan 13 2020, 11:22 PM
romangg removed romangg as the assignee of this task.Apr 23 2020, 5:01 PM
romangg closed this task as Wontfix.
romangg claimed this task.