1. 06 Jan, 2021 2 commits
    • Vlad Zahorodnii's avatar
      Drop flag to indicate if swap buffers is blocking · 7a3fa88f
      Vlad Zahorodnii authored
      We want the new compositing timing algorithm to be invariant regarding
      whether glXSwapBuffers() or eglSwapBuffers() block.
    • Vlad Zahorodnii's avatar
      Swap buffers after finishing a compositing cycle · 0ceff5fd
      Vlad Zahorodnii authored
      The compositing timing algorithm assumes that glXSwapBuffers() and
      eglSwapBuffers() block. While this was true long time ago with NVIDIA
      drivers, nowadays, it's not the case. The NVIDIA driver queues
      several buffers in advance and if the application runs out of them,
      it will block. With Mesa driver, swapping buffer was never blocking.
      This change makes the render backends swap buffers right after ending
      a compositing cycle. This may potentially block, but it shouldn't be
      an issue with modern drivers. In case it gets proven, we can move
      glXSwapBuffers() and eglSwapBuffers() in a separate thread.
      Note that this change breaks the compositing timing algorithm, but
      it's already sort of broken with Mesa drivers.
  2. 10 Dec, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Provide expected presentation time to effects · 9f2cb0ae
      Vlad Zahorodnii authored
      Effects are given the interval between two consecutive frames. The main
      flaw of this approach is that if the Compositor transitions from the idle
      state to "active" state, i.e. when there is something to repaint,
      effects may see a very large interval between the last painted frame and
      the current. In order to address this issue, the Scene invalidates the
      timer that is used to measure time between consecutive frames before the
      Compositor is about to become idle.
      While this works perfectly fine with Xinerama-style rendering, with per
      screen rendering, determining whether the compositor is about to idle is
      rather a tedious task mostly because a single output can't be used for
      the test.
      Furthermore, since the Compositor schedules pointless repaints just to
      ensure that it's idle, it might take several attempts to figure out
      whether the scene timer must be invalidated if you use (true) per screen
      Ideally, all effects should use a timeline helper that is aware of the
      underlying render loop and its timings. However, this option is off the
      table because it will involve a lot of work to implement it.
      Alternative and much simpler option is to pass the expected presentation
      time to effects rather than time between consecutive frames. This means
      that effects are responsible for determining how much animation timelines
      have to be advanced. Typically, an effect would have to store the
      presentation timestamp provided in either prePaint{Screen,Window} and
      use it in the subsequent prePaint{Screen,Window} call to estimate the
      amount of time passed between the next and the last frames.
      Unfortunately, this is an API incompatible change. However, it shouldn't
      take a lot of work to port third-party binary effects, which don't use the
      AnimationEffect class, to the new API. On the bright side, we no longer
      need to be concerned about the Compositor getting idle.
      We do still try to determine whether the Compositor is about to idle,
      primarily, because the OpenGL render backend swaps buffers on present,
      but that will change with the ongoing compositing timing rework.
  3. 02 Dec, 2020 1 commit
  4. 11 Nov, 2020 2 commits
  5. 04 Nov, 2020 1 commit
  6. 03 Nov, 2020 1 commit
    • Vlad Zahorodnii's avatar
      scene: Stop monitoring changes for unmapped surfaces · 47ea0c98
      Vlad Zahorodnii authored
      Once the main surface has been unmapped, we are no longer interested in
      any changes that indicate that the window quads cache should be discarded
      This also fixes a bug where the scene holds a subsurface monitor object
      even after the associated window has been destroyed.
  7. 02 Nov, 2020 1 commit
  8. 30 Oct, 2020 2 commits
    • Vlad Zahorodnii's avatar
      Report partial updates on all outputs · d5203c79
      Vlad Zahorodnii authored
      Previously, we couldn't do it because repaints weren't tracked per each
    • Vlad Zahorodnii's avatar
      Store repaint regions per individual screen · 74391e25
      Vlad Zahorodnii authored
      AnimationEffect schedules repaints in postPaintWindow() and performs
      cleanup in preScreenPaint(). With the X11-style rendering, this doesn't
      have any issues, scheduled repaints will be reset during the next
      compositing cycle.
      But with per screen rendering, we might hit the following case
          - Paint screen 0
          - Reset scheduled repaints
          - AnimationEffect::prePaintScreen(): update the timeline
          - AnimationEffect::postPaintScreen(): schedule a repaint
          - Paint screen 1
          - Reset scheduled repaints
          - AnimationEffect::prePaintScreen(): destroy the animation
          - AnimationEffect::postPaintScreen(): no repaint is scheduled
          - Return to the event loop
      In this scenario, the repaint region scheduled by AnimationEffect will
      be lost when compositing is performed on screen 1.
      There is no any other way to fix this issue but maintain repaint regions
      per each individual screen if per screen rendering is enabled.
      BUG: 428439
  9. 26 Oct, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Clip software cursors · 4a0128ca
      Vlad Zahorodnii authored
      If you play some video and the software cursor doesn't hover it, then
      the shadow cast by the cursor will be getting darker and darker with
      every frame.
      The main reason for that is that kwin paints the software cursor even
      if the rect behind it hasn't been damaged or repainted.
  10. 19 Oct, 2020 1 commit
    • Vlad Zahorodnii's avatar
      screencast: Use fences to avoid stalling the graphics pipeline · 9c20df50
      Vlad Zahorodnii authored
      Currently, we use glFinish() to ensure that stream consumers don't see
      corrupted or rather incomplete buffers. This is a serious issue because
      glFinish() not only prevents the gpu from processing new GL commands,
      but it also blocks the compositor.
      This change addresses the blocking issue by using native fences. With
      the proposed change, after finishing recording a frame, a fence is
      inserted in the command stream. When the native fence is signaled, the
      pending pipewire buffer will be enqueued.
      If the EGL_ANDROID_native_fence_sync extension is not supported, we'll
      fall back to using glFinish().
  11. 13 Oct, 2020 1 commit
  12. 22 Sep, 2020 1 commit
    • Aleix Pol Gonzalez's avatar
      Centralize WindowPixmap buffer updating code · 61e655f7
      Aleix Pol Gonzalez authored
      Uses a setter and clear method pattern rather than having the code
      Instead of keeping a QPointer, now we are a QObject and we get notified
      about destruction intention directly, so we can clear the pointer when
  13. 09 Sep, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Properly handle opaque regions for CSD X11 windows · 2b241d30
      Vlad Zahorodnii authored
      Currently, we don't compute the clip region properly for some client-
      side decorated applications, for example gedit, due to mixing several
      separate coordinate spaces.
      This change ensures that the window pixmap shape and the opaque region
      are in the same coordinate space - the window pixmap coordinate.
      In order to simplify mapping regions from the window pixmap coordinates
      to the global screen coordinates, a new helper method was introduced in
      the WindowPixmap class - mapToGlobal().
  14. 19 Aug, 2020 1 commit
    • Aleix Pol Gonzalez's avatar
      Implement EGL_KHR_partial_update and EGL_EXT_swap_buffers_with_damage · eeeac049
      Aleix Pol Gonzalez authored
      Notify the driver about the parts of the screen that will be repainted.
      In some cases this can be benefitial. This is especially useful on lima
      and panfrost devices (e.g. pinephone, pinebook, pinebook pro).
      Test Plan:
      Tested on a pinebook pro with a late mesa version.
      Basically I implemented it, then it didn't work and I fixed it.
      Maybe next step we want to look into our damage algorithm.
  15. 07 Aug, 2020 2 commits
    • Vlad Zahorodnii's avatar
      Prettify license headers · 4ce853e8
      Vlad Zahorodnii authored
    • Vlad Zahorodnii's avatar
      Switch to SPDX license markers · 1fb9f6f1
      Vlad Zahorodnii authored
      The main advantage of SPDX license identifiers over the traditional
      license headers is that it's more difficult to overlook inappropriate
      licenses for kwin, for example GPL 3. We also don't have to copy a
      lot of boilerplate text.
      In order to create this change, I ran licensedigger -r -c from the
      toplevel source directory.
  16. 23 Jul, 2020 1 commit
  17. 10 Jun, 2020 3 commits
    • Vlad Zahorodnii's avatar
      [scene] Setup scene window connections with correct receiver object · c890996a
      Vlad Zahorodnii authored
      We need a couple of connections to ensure that the window pixmap, the
      window quad cache, and the window shape get discarded when the geometry
      of the toplevel has been changed. Currently, those connections are
      created with the receiver object being the scene. The problem is that
      the associated wayland surface may outlive the toplevel and we don't
      cleanup the connections after the scene window has been destroyed.
      The fact that the connections don't get destroyed can lead to accessing
      dangling pointers, which may result in a crash.
      In order to ensure that the connections are broken automatically when
      the scene window is destroyed, we need to ensure that the received
      object is the scene window. That way, the connections will be destroyed
    • Vlad Zahorodnii's avatar
      [scene] Rename a scene window method · 430b63d1
      Vlad Zahorodnii authored
      This change renames invalidateQuadsCache() to discardQuads() because the
      latter name is shorter and it aligns with pre-existing method names.
    • Vlad Zahorodnii's avatar
      [scene] Make the scene window a qobject · cb4dc0ff
      Vlad Zahorodnii authored
      Since the scene window is not a QObject, we cannot connect toplevel's
      signals directly to the scene window's slots.
  18. 03 Jun, 2020 1 commit
    • Vlad Zahorodnii's avatar
      [scene] Introduce helpers for mapping between different coordinate spaces · 9e797cf9
      Vlad Zahorodnii authored
      We currently deal with three distinct coordinate spaces - the window
      pixmap coordinate space, the window coordinate space, and the buffer
      pixel coordinate space.
      This change introduces a couple of helper methods to make it easier
      to map points from the window pixmap space to the other two spaces.
      The main motivation behind the new helpers is to break the direct
      relationship between the surface-local coordinates and buffer pixel
      coordinates for wayland surfaces.
  19. 02 Jun, 2020 1 commit
  20. 04 May, 2020 3 commits
    • Vlad Zahorodnii's avatar
      [scene] Generate window quads for sub-surfaces · f2c8981f
      Vlad Zahorodnii authored
      No window quads are generated for sub-surfaces right now. This leads to
      issues with effects that operate on window quads, e.g. magic lamp and
      wobbly windows. Furthermore, the OpenGL scene needs window quads to
      properly clip windows during the rendering process.
      The best way to render sub-surfaces would be with a little help from a
      scene graph. Contrary to GNOME, KDE hasn't developed any scene graph
      implementation that we could use in kwin. As a short term solution, this
      change adjusts the scene to generate window quads.
      Window quads are generated as we traverse the current window pixmap tree
      in the depth-first search manner. In order to match a list of quads with
      a particular WindowPixmap, we assign an id to each quad.
      BUG: 387313
      FIXED-IN: 5.19.0
      Differential Revision: https://phabricator.kde.org/D29131
    • Vlad Zahorodnii's avatar
      [scene] Release previous pixmap when a raster buffer is attached · 2d88fd0e
      Vlad Zahorodnii authored
      We need to release the previous window pixmap if the new pixmap is
      valid. However, it's currently the case only when the client has
      attached either an fbo buffer or a wl_buffer. If an internal client
      has attached a raster buffer, the previous window pixmap won't be
      In order to ensure that we're going to release the previous window
      pixmaps no matter what type of buffer has been attached, this change
      refactors WindowPixmap to use isValid() to verify that the new
      window pixmap is valid.
      Differential Revision: https://phabricator.kde.org/D29131
    • Vlad Zahorodnii's avatar
      [scene] Build window pixmap trees before starting rendering · e4b598ca
      Vlad Zahorodnii authored
      In order to generate window quads for sub-surfaces, we need a valid
      window pixmap tree. The problem is that the window pixmap tree is
      created too late in the rendering process. This change adjusts the
      scene so it creates window pixmap trees before buildQuads().
      Differential Revision: https://phabricator.kde.org/D29131
  21. 30 Apr, 2020 1 commit
  22. 20 Apr, 2020 1 commit
    • Méven Car's avatar
      Wayland: Allow to take single screen screenshots using scale factor without loss · 66898e7f
      Méven Car authored
      The screenshot made on screens with scale factor were downscaled by their scale factor making them blurry.
      It prevents taking screenshots of missing Hidpi related bugs showing the issues under Wayland.
      This fix the case of a single screenshot, but not the rest:
      Multiscreen screenshot downscales the screen using scale factor.
      Spectacle rectangular selection screenshot is broken as soon as some scale factor different than 1 is used on any screen.
      Test Plan:
      Under Wayland with a scale factor on a screen, take a screenshot using spectacle.
      The output image is not downscaled and has the same size as the screen resolution.
      No other change to any other screenshot mode, or under X.
      Reviewers: davidedmundson, #kwin
      Reviewed By: davidedmundson, #kwin
      Subscribers: kwin
      Tags: #kwin
      Differential Revision: https://phabricator.kde.org/D29010
  23. 14 Mar, 2020 1 commit
  24. 03 Feb, 2020 1 commit
    • Vlad Zahorodnii's avatar
      [x11] Fix visual artifacts during interactive resize · 56d5f3a4
      Vlad Zahorodnii authored
      When a window is being interactively resized, its contents may jump. The
      reason why that happens is because KWin renders partially resized client
      window. Composite extension spec says that a window will get a new pixmap
      each time it is resized or mapped. This applies to the frame window, but
      not to the client window itself. If the client window is resized,
      off-screen storage for the frame window won't be reallocated. Therefore,
      KWin may render partially resized client window if the client doesn't
      attempt to be in sync with our rendering loop. Currently, the only way
      to do that is to use extended frame counters, which are not supported by
      So, in order to fix visual artifacts during interactive resize, we need
      somehow forcefully re-allocate off-screen storage for the frame window.
      Unfortunately, Composite extension doesn't provide any request to do
      that, so the only option we have is to resize the frame window.
      BUG: 415839
      FIXED-IN: 5.18.0
      Reviewers: #kwin
      Subscribers: davidedmundson, ngraham, alexde, fredrik, kwin
      Tags: #kwin
      Differential Revision: https://phabricator.kde.org/D26914
  25. 16 Jan, 2020 3 commits
  26. 12 Dec, 2019 1 commit
    • Roman Gilg's avatar
      Add hasSwapEvent getter · a55dee3b
      Roman Gilg authored
      Add a small getter to query information internally if the backend supports
      swap events. Defaults to true as it is the default in the GBM Wayland backend.
      Test Plan: i915
      Reviewers: #kwin
      Subscribers: kwin
      Tags: #kwin
      Maniphest Tasks: T11071
      Differential Revision: https://phabricator.kde.org/D25298
  27. 02 Dec, 2019 2 commits
    • Vlad Zahorodnii's avatar
      Revert the fix for the texture bleeding issue · 6e000314
      Vlad Zahorodnii authored
      This reverts commit 9151bb7b.
      This reverts commit ac4dce1c.
      This reverts commit 754b72d1.
      In order to make the fix work, we need to redirect the client window
      instead of the frame window. However, we cannot to do that because
      Xwayland expects the toplevel window(in our case, the frame window)
      to be redirected.
      Another solution to the texture bleeding issue must be found.
      CCBUG: 257566
      CCBUG: 360549
    • Vlad Zahorodnii's avatar
      [x11] Name client pixmap instead of frame pixmap · 754b72d1
      Vlad Zahorodnii authored
      Since KDE 4.2 - 4.3 times, KWin doesn't paint window decorations on real
      X11 windows, except when compositing is turned off. This leaves us with
      a problem. The actual client contents is inside a larger texture with no
      useful pixel data around it. This and decoration texture bleeding are
      the main factors that contribute to 1px gap between the server-side
      decoration and client contents with effects such as wobbly windows, and
      Another problem with naming frame pixmap instead of client pixmap is
      that it doesn't quite go along with wayland. It only makes more difficult
      to abstract window quad generation in the scene.
      Since we don't actually need the frame window when compositing is on,
      there is nothing that holds us from redirecting client windows instead
      of frame windows. This will help us to fix the texture bleeding issue
      and also help us with the ongoing redesign of the scene.
      Test Plan: X11 clients are still composited.
      Reviewers: #kwin, davidedmundson
      Reviewed By: #kwin, davidedmundson
      Subscribers: davidedmundson, kwin
      Tags: #kwin
      Differential Revision: https://phabricator.kde.org/D25610
  28. 27 Nov, 2019 2 commits
    • Vlad Zahorodnii's avatar
      Drop some custom list typedefs · 9d4a3259
      Vlad Zahorodnii authored
      Qt has its own thing where a type might also have corresponding list
      alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't
      know why Qt does that, maybe for some historical reasons, but what
      matters is that we copy this pattern here in KWin. While this pattern
      might be useful with some long list types, for example
          QList<QWeakPointer<TabBoxClient>> TabBoxClientList
      in general, it causes more harm than good. For example, we've got two
      new client types, do we need corresponding list typedefs for them? If
      no, why do we have ClientList and so on?
      Another problem with these typedefs is that you need to include utils.h
      header in order to use them. A better way to handle such things is to
      just forward declare a client class (if that's possible) and use it
      directly with QList or QVector. This way translation units don't get
      "bloated" with utils.h stuff for no apparent reason.
      So, in order to make code more consistent and easier to follow, this
      change d...
    • Vlad Zahorodnii's avatar
      Adjust scene for client-side decorated clients · fb2d4c11
      Vlad Zahorodnii authored
      Currently our Scene is quite naive about geometry. It assumes that the
      window frame wraps the attached buffer/client. While this is true for X11
      clients, such geometry model is not suitable for client-side decorated
      clients, in our case for xdg-shell clients that set window geometry
      other than the bounding rectangle of the main surface.
      In general, the proposed solution doesn't make any concrete assumptions
      about the order between frame and buffer geometry, however we may still
      need to reconsider the design of Scene once it starts to generate quads
      for sub-surfaces.
      Reviewers: #kwin, davidedmundson
      Reviewed By: #kwin, davidedmundson
      Subscribers: davidedmundson, romangg, kwin
      Tags: #kwin
      Maniphest Tasks: T10867
      Differential Revision: https://phabricator.kde.org/D24462