1. 01 Jul, 2020 1 commit
    • Vlad Zahorodnii's avatar
      [scene] Discard pixmaps on buffer size change · 617650d4
      Vlad Zahorodnii authored
      The surface size is a logical size, which renders it unsuitable for
      deciding whether the window pixmap needs to be discarded.
      
      We need to discard window pixmaps when the buffer size changes. That
      has a drawback though, discarding textures is kind of an overkill with
      linux-dmabuf. However, fixing that would involve changes in kwayland
      server that are far from being trivial.
      
      BUG: 422459
      617650d4
  2. 24 Jun, 2020 1 commit
  3. 19 Jun, 2020 1 commit
  4. 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
      automatically.
      c890996a
    • 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.
      430b63d1
    • 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.
      cb4dc0ff
  5. 03 Jun, 2020 2 commits
    • Vlad Zahorodnii's avatar
      [wayland] Add support for cropped and scaled surfaces · de2c4cb4
      Vlad Zahorodnii authored
      The wp_viewporter compositor extension allows clients to crop and scale
      their surfaces. It can be especially useful for applications wishing to
      reduce their power consumption, e.g. video players, etc.
      
      Given that there is no any direct relationship between the surface size
      and the buffer size anymore, we have to use specialized helper methods
      for converting coordinates from the surface-local space to buffer pixel
      space and vice versa.
      de2c4cb4
    • 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.
      9e797cf9
  6. 19 May, 2020 1 commit
    • Vlad Zahorodnii's avatar
      [scene] Re-build window quads after creating a WindowPixmap · 7569bdf6
      Vlad Zahorodnii authored
      In order to generate window quads for a window, the scene needs a valid
      WindowPixmap tree. If it's time to render the window, the scene will
      build window quads for the contents, the server-side window decoration,
      the drop-shadow and cache the resulting window quads. With this way of
      generating window quads, we need the window pixmap tree to be valid,
      or else no contents window quads will be generated.
      
      While the window pixmap tree is guaranteed to be valid at the time of
      generation of window quads for Wayland and X11 clients, this is not the
      case for Xwayland clients.
      
      When an Xwayland client is created, some time may pass between the
      moment it's been created and the moment when a regular wayland surface
      has been associated with the xwayland window. If the compositor decides
      to render the Xwayland client in that short period of time, the window
      quads cache won't have window quads cache.
      
      In order to work around the weird asynchronous behavior of Xwayland
      clients, this change makes the scene discard the window quad cache when
      a new window pixmap has been created. This will ensure that the current
      window quads are always in sync with the current window pixmap tree.
      7569bdf6
  7. 04 May, 2020 5 commits
  8. 30 Apr, 2020 1 commit
  9. 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
      Summary:
      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
      66898e7f
  10. 14 Apr, 2020 1 commit
    • Jacopo De Simoi's avatar
      Fix fullRepaints loop · a2fc6f8e
      Jacopo De Simoi authored
      The method paintSimpleScreen is responsible for redrawing the parts of
      the back-buffer that need updating using the buffer_age extension.
      The method fails to set correctly the damaged_region if, for some
      reason, one frame needs a repaint of the whole screen. In this case
      the backbuffer will request a full-screen repaint at some future
      frame, so the dirty region will be extended to full-screen. However,
      in this case the repaintRegion is not subtracted from the
      damaged_region (as it is done for the non fullRepaints case below
      --see the comment below--) and the damaged_region is reported to be the full
      screen again. This causes all the subsequent frames to be reported
      with a full screen damage, which causes some penalty, until
      paintGenericScreen is invoked for some reason and then the damage gets
      reset correctly.
      
      We now set the correct damage and prevent falling into the fullRepaint
      loop.
      a2fc6f8e
  11. 19 Mar, 2020 1 commit
    • Vlad Zahorodnii's avatar
      [wayland] Recursively destroy WindowPixmap objects · 25276d30
      Vlad Zahorodnii authored
      Summary:
      We need to destroy the root WindowPixmap together with all of its
      children; otherwise, buffers that are attached to subsurfaces will
      not be released.
      
      Test Plan:
      weston-subsurfaces doesn't quit with an error message saying that
      all buffers are held by the compositor.
      
      Reviewers: #kwin, davidedmundson
      
      Reviewed By: #kwin, davidedmundson
      
      Subscribers: kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D28145
      25276d30
  12. 14 Mar, 2020 1 commit
  13. 03 Feb, 2020 1 commit
    • Vlad Zahorodnii's avatar
      [x11] Fix visual artifacts during interactive resize · 56d5f3a4
      Vlad Zahorodnii authored
      Summary:
      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
      KWin.
      
      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
      56d5f3a4
  14. 29 Jan, 2020 1 commit
  15. 16 Jan, 2020 3 commits
  16. 09 Jan, 2020 1 commit
    • Vlad Zahorodnii's avatar
      [scene] Fix decoration texture bleeding · af71763b
      Vlad Zahorodnii authored
      Summary:
      Quite long time ago, window decorations were painted on real X11 windows.
      The nicest thing about that approach is that we get both contents of the
      client and the frame window at the same time. However, somewhere around
      KDE 4.2 - 4.3 times, decoration rendering architecture had been changed
      to what we have now.
      
      I've mentioned the previous decoration rendering design because it didn't
      have a problem that the new design has, namely the texture bleeding issue.
      
      In the name of better performance, opengl scene puts all decoration parts
      to an atlas. This is totally reasonable, however we must be super cautious
      about things such as the GL_LINEAR filter.
      
      The GL_LINEAR filter may need to sample a couple of neighboring texels
      in order to produce the final texel value. However, since all decoration
      parts now live in a single texture, we have to make sure that we don't
      sample texels that belong to another decoration part.
      
      This patch fixes the texture bleeding problem by padding each individual
      decoration part in the atlas. There is another solution for this problem
      though. We could render a window into an offscreen texture and then map
      that texture on the transformed window geometry. This would work well and
      we definitely need an offscreen rendering path in the opengl scene,
      however it's not feasible at the moment since we need to break the window
      quads API. Also, it would be great to have as less as possible stuff going
      on between invocation of Scene::Window::performPaint() and getting the
      corresponding pixel data on the screen.
      
      There is a good chance that the new padding stuff may make you vomit. If
      it does so, I'm all ears for the suggestions how to make the code more
      nicer.
      
      BUG: 257566
      BUG: 360549
      CCBUG: 412573
      FIXED-IN: 5.18.0
      
      Reviewers: #kwin
      
      Subscribers: fredrik, kwin, fvogt
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D25611
      af71763b
  17. 13 Dec, 2019 1 commit
    • Marco Martin's avatar
      fix thumbnails positioning · d593f24d
      Marco Martin authored
      to have the scene position of the thumbnail, you need
      item->mapToScene(QPointF(0,0)); and not add to that its parent-relative position
      d593f24d
  18. 12 Dec, 2019 1 commit
    • Roman Gilg's avatar
      Add hasSwapEvent getter · a55dee3b
      Roman Gilg authored
      Summary:
      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
      a55dee3b
  19. 02 Dec, 2019 3 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
      6e000314
    • Vlad Zahorodnii's avatar
      [scene] Fix decoration texture bleeding · ac4dce1c
      Vlad Zahorodnii authored
      Summary:
      Quite long time ago, window decorations were painted on real X11 windows.
      The nicest thing about that approach is that we get both contents of the
      client and the frame window at the same time. However, somewhere around
      KDE 4.2 - 4.3 times, decoration rendering architecture had been changed
      to what we have now.
      
      I've mentioned the previous decoration rendering design because it didn't
      have a problem that the new design has, namely the texture bleeding issue.
      
      In the name of better performance, opengl scene puts all decoration parts
      to an atlas. This is totally reasonable, however we must be super cautious
      about things such as the GL_LINEAR filter.
      
      The GL_LINEAR filter may need to sample a couple of neighboring texels
      in order to produce the final texel value. However, since all decoration
      parts now live in a single texture, we have to make sure that we don't
      sample texels that belong to another decoration part.
      
      This patch fixes the texture bleeding problem by padding each individual
      decoration part in the atlas. There is another solution for this problem
      though. We could render a window into an offscreen texture and then map
      that texture on the transformed window geometry. This would work well and
      we definitely need an offscreen rendering path in the opengl scene,
      however it's not feasible at the moment since we need to break the window
      quads API. Also, it would be great to have as less as possible stuff going
      on between invocation of Scene::Window::performPaint() and getting the
      corresponding pixel data on the screen.
      
      There is a good chance that the new padding stuff may make you vomit. If
      it does so, I'm all ears for the suggestions how to make the code more
      nicer.
      
      BUG: 257566
      BUG: 360549
      CCBUG: 412573
      FIXED-IN: 5.18.0
      
      Reviewers: #kwin
      
      Subscribers: fredrik, kwin, fvogt
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D25611
      ac4dce1c
    • Vlad Zahorodnii's avatar
      [x11] Name client pixmap instead of frame pixmap · 754b72d1
      Vlad Zahorodnii authored
      Summary:
      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
      zoom.
      
      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
      754b72d1
  20. 27 Nov, 2019 3 commits
    • Vlad Zahorodnii's avatar
      Drop some custom list typedefs · 9d4a3259
      Vlad Zahorodnii authored
      Summary:
      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 drops some of our custom typedefs. Namely ConstClientList,
      ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList.
      
      Test Plan: Compiles.
      
      Reviewers: #kwin
      
      Subscribers: kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D24950
      9d4a3259
    • Vlad Zahorodnii's avatar
      Adjust scene for client-side decorated clients · fb2d4c11
      Vlad Zahorodnii authored
      Summary:
      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
      fb2d4c11
    • Vlad Zahorodnii's avatar
      Fix coding style issues in Scene::paintSimpleScreen · 14dc76f6
      Vlad Zahorodnii authored
      Reviewers: #kwin, romangg
      
      Reviewed By: #kwin, romangg
      
      Subscribers: romangg, fredrik, kwin
      
      Tags: #kwin
      
      Maniphest Tasks: T10867
      
      Differential Revision: https://phabricator.kde.org/D24461
      14dc76f6
  21. 14 Nov, 2019 2 commits
    • Roman Gilg's avatar
      [platforms/x11] Never block on retrace, always present after paint · 8d137290
      Roman Gilg authored
      Summary:
      Compositing in X11 was done time shifted, meaning that we paint first, then
      wait one vblank interval length and present on prepareRenderingFrame the
      previous paint result. This is supposed to make sure we don't miss the vblank
      and in case of block till retrace be able to continue issuing commands and
      only shortly before next vblank present.
      
      This is counter-intuitiv, not how we do it on Wayland or even on MESA with X.
      The reason seems to be that the GLX backend was in the beginning written
      against Nvidia proprietary driver which needed this but nowadays even this
      driver defaults to non-blocking behavior on buffer swap.
      
      Therefore remove this legacy anomaly fully and directly present after paint.
      We then wait one refresh cycle and in the future can optimize this by delaying
      the paint and present till shortly before vsync.
      
      Test Plan: kwin_x11 tested on i915 and Nvidia proprietary driver.
      
      Reviewers: #kwin
      
      Subscribers: zzag, alexeymin, kwin
      
      Tags: #kwin
      
      Maniphest Tasks: T11071
      
      Differential Revision: https://phabricator.kde.org/D23514
      8d137290
    • Roman Gilg's avatar
      Remove vsync detection and configurability · b3a19f9e
      Roman Gilg authored
      Summary:
      Selecting not to vsync does not make sense for an X11 compositor. In the end
      we want clients to be able to present async if they want to but the compositor
      is supposed to send swaps with vsync to the XServer in order to not generate
      tearing artifacts.
      
      There was also a detection logic which did some questionable things in case
      vsync was not available. I don't think this is necessary at all since we can
      just always run a timer to present with or without vsync.
      
      Test Plan: kwin_x11 tested on i915.
      
      Reviewers: #kwin, zzag
      
      Subscribers: zzag, kwin
      
      Tags: #kwin
      
      Maniphest Tasks: T11071
      
      Differential Revision: https://phabricator.kde.org/D23511
      b3a19f9e
  22. 29 Sep, 2019 1 commit
  23. 25 Sep, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Rename Client to X11Client · ffcbe24e
      Vlad Zahorodnii authored
      Summary:
      Currently each managed X11 client is represented with an instance of
      Client class, however the name of that class is very generic and the
      only reason why it's called that way is because historically kwin
      was created as an x11 window manager, so "Client" was a sensible choice.
      
      With introduction of wayland support, things had changed and therefore
      Client needs to be renamed to X11Client in order to better reflect what
      that class stands for.
      
      Renaming of Client to X11Client was agreed upon during the last KWin
      sprint.
      
      Test Plan: Compiles, the test suite is still green.
      
      Reviewers: #kwin, romangg
      
      Reviewed By: #kwin, romangg
      
      Subscribers: romangg, davidedmundson, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D24184
      ffcbe24e
  24. 23 Sep, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Port QPA away from Wayland · bebe8120
      Vlad Zahorodnii authored
      Summary:
      So far wayland was used by internal clients to submit raster buffers
      and position themselves on the screen. While we didn't have issues with
      submitting raster buffers, there were some problems with positioning
      task switchers. Mostly, because we had effectively two paths that may
      alter geometry.
      
      A better approach to deal with internal clients is to let our QPA use
      kwin core api directly. This way we can eliminate unnecessary roundtrips
      as well make geometry handling much easier and comprehensible.
      
      The last missing piece is shadows. Both Plasma::Dialog and Breeze widget
      style use platform-specific APIs to set and unset shadows. We need to
      add shadows API to KWindowSystem. Even though some internal clients lack
      drop-shadows at the moment, I don't consider it to be a blocker. We can
      add shadows back later on.
      
      CCBUG: 386304
      
      Reviewers: #kwin, davidedmundson, romangg
      
      Reviewed By: #kwin, romangg
      
      Subscribers: romangg, kwin
      
      Tags: #kwin
      
      Maniphest Tasks: T9600
      
      Differential Revision: https://phabricator.kde.org/D22810
      bebe8120
  25. 19 Sep, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Use nullptr everywhere · 62a7db70
      Vlad Zahorodnii authored
      Summary:
      Because KWin is a very old project, we use three kinds of null pointer
      literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
      nullptr keyword.
      
      This change converts all usages of 0 and NULL literal to nullptr. Even
      though it breaks git history, we need to do it in order to have consistent
      code as well to ease code reviews (it's very tempting for some people to
      add unrelated changes to their patches, e.g. converting NULL to nullptr).
      
      Test Plan: Compiles.
      
      Reviewers: #kwin, davidedmundson, romangg
      
      Reviewed By: #kwin, davidedmundson, romangg
      
      Subscribers: romangg, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D23618
      62a7db70
  26. 14 Sep, 2019 1 commit