Announcement

Collapse
No announcement yet.

Compositing Window Managers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Compositing Window Managers

    I understand, how the compositing windows managers interfere with overall gaming performance, including vsync, as games (all other apps) get rendered indirectly.
    Basically, every window is redirected to an offscreen buffer, and the composite manager draws them 'manually' onto the root window (e.g. including shadows and other visual effects).

    KWin and Compiz offer the possibility to disable the composition for fullscreen root windows, which works ok (except for e.g. multi monitor setups or non-fullscreen games).

    Wouldn't it make sense, to generally disable composition for the foremost/focused window (as long as it's not transparent), and just draw all other windows, as well as the shadows (including the shadow of the foremost window) to the root window image?

    That should (imho) work for all games/apps, and the framerate/vsync won't depend on the compositing window manage anymore. Or do i miss anything?

  • #2
    That would still mean that you have to render all the other windows in a redirected fashion. When you have a fullscreen unredirected app or the compositor off, everything is rendered directly.

    Comment


    • #3
      right. but that way you could still give full performance to the foremost (non-redirected) window, while the compositor could render the others when idle.
      E.g. a game in the foremost/focus window could run with 60 fps, while the compositor renders the others with 20 fps.

      Comment


      • #4
        What about effects on the foremost window (wobbly window on moving, window preview in the task bar, etc.)? You would have to redirect it at least as long as the effect is active and maybe have annoying flickering when switching between direct and redirected rendering.

        Comment


        • #5
          When applying (e.g. wobbly) effects, the comp manager would have to composite it for that period of time.
          Why do you think that it would be flickering? And even if it is for 1 frame, wouldn't that be worth the performance improvement?

          Other desktop effects like window previews are possible using e.g. x(shm)getimage, and can easily be optimized using XDamage.

          Comment


          • #6
            You would have to redirect it at least as long as the effect is active

            Comment


            • #7
              Originally posted by moony View Post
              Why do you think that it would be flickering? And even if it is for 1 frame, wouldn't that be worth the performance improvement?
              Well, I don't know anything about the internals, just my experience with kwin. When disabling compositing all my chromium windows go blank for a short time and when enabling compositing the window decorations flicker. Maybe it could be implemented better, I don't know.

              Maybe some effects can be replaced with other methods but there are still lots of effects to cover. Maybe they aren't useful but they are available in compiz and kwin, etc like controlling transparency, saturation, contrast, etc. of windows or zooming the whole desktop...

              Comment


              • #8
                @ChrisXY, i did some tests using pygtk, it's possible to turn composite on and off without any flickering.
                So if something flickers, it's rather an issue in the implementation.

                In general, I don't want to get rid of composition, but it should get optimized more aggressively. If there aren't effects or transparency required on foremost windows (should be the cast for most apps/games, unlike semi-transparent consoles), why not allow direct rendering?
                Last edited by moony; 23 November 2012, 08:54 AM.

                Comment

                Working...
                X