1. 30 Sep, 2019 1 commit
  2. 27 Sep, 2019 1 commit
    • David Edmundson's avatar
      [libkwineffects] Introduce API to easily show a QtQuick scene in an effect · 40b0296d
      David Edmundson authored
      EffectQuickView/Scene is a convenient class to render a QtQuick
      scenegraph into an effect.
      Current methods (such as present windows) involve creating an underlying
      platform window which is expensive, causes a headache to filter out
      again in the rest of the code, and only works as an overlay.
      The new class exposes things more natively to an effect where we don't
      mess with real windows, we can perform the painting anywhere in the view
      and we don't have issues with hiding/closing.
      QtQuick has both software and hardware accelerated modes, and kwin also
      has 3 render backends. Every combination is supported.
      * When used in OpenGL mode for both, we render into an FBO export the
      texture ID then it's up to the effect to render that into a scene.
      * When using software QtQuick rendering we blit into an image, upload
      that into a KWinGLTexture which serves as an abstraction layer and
      render that into the scene.
      * When using GL for QtQuick and XRender/QPainter in kwin everything is
      rendered into the internal FBO, blit and exported as an image.
      * When using software rendering for both an image gets passed directly.
      Mouse and keyboard events can be forwarded, only if the effect
      intercepts them.
      The class is meant to be generic enough that we can remove all the
      QtQuick code from Aurorae.
      The intention is also to replace EffectFrameImpl using this backend and
      we can kill all of the EffectFrame code throughout the scenes.
      The close button in present windows will also be ported to this,
      simplifiying that code base.
      Classes that handle the rendering and handling QML are intentionally
      split so that in the future we can have a declarative effects API create
      overlays from within the same context. Similar to how one can
      instantiate windows from a typical QML scene.
      I don't like how I pass the kwin GL context from the backends into the
      effect, but I need something that works with the library separation. It
      also currently has wayland problem if I create a QOpenGLContext before
      the QPA is set up with a scene - but I don't have anything better?
      I know for the EffectFrame we need an API to push things through the
      effects stack to handle blur/invert etc. Will deal with that when we
      port the EffectFrame.
      Test Plan: Used in an effect
      Reviewers: #kwin, zzag
      Reviewed By: #kwin, zzag
      Subscribers: zzag, kwin
      Tags: #kwin
      Differential Revision: https://phabricator.kde.org/D24215
  3. 25 Sep, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Rename Client to X11Client · ffcbe24e
      Vlad Zahorodnii authored
      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
      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
  4. 23 Sep, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Port QPA away from Wayland · bebe8120
      Vlad Zahorodnii authored
      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
  5. 19 Sep, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Use nullptr everywhere · 62a7db70
      Vlad Zahorodnii authored
      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
  6. 09 Jul, 2019 1 commit
  7. 07 Jun, 2018 1 commit
    • Vlad Zahorodnii's avatar
      [scenes/qpainter] Draw decoration shadows · 2d01ba64
      Vlad Zahorodnii authored
      QPainter doesn't render decoration shadows. It renders only
      shadows provided through ShadowInterface.
      With this change, painting of shadows is done in similar way OpenGL backend is
      currently doing.
      {F5734867, layout=center, size=full}
      {F5734870, layout=center, size=full}
      Depends on D10811 (dummy decoration with shadows in autotests)
      Test Plan:
      * start kwin with QPainter backend enabled:
      KWIN_COMPOSE=Q kwin_wayland --xwayland --windowed
      * open konsole and kate:
      DISPLAY=:1 konsole
      DISPLAY=:1 kate
      Reviewers: #kwin, graesslin, davidedmundson
      Reviewed By: davidedmundson
      Subscribers: abetts, kwin
      Tags: #kwin
      Differential Revision: https://phabricator.kde.org/D10943
  8. 01 Nov, 2017 1 commit
    • David Edmundson's avatar
      Render GL Window decorations at the correct scale · fc887ab9
      David Edmundson authored
      Under wayland we support high DPI putting by putting a separation
      between the logical co-ordinate system and the resolution of rendered
      When a window is on a high DPI screen, we should render at the higher
      Like the window scaling this handles any combination of a 2x scaled
      decoration being rendered on a 1x screen or vice versa.
      This patch is a bit different from the other scaling stuff. We have to
      generate the quads *before* we have an updated texture with the new
      scale. This means the scale isn't attached to the buffer like elsewhere.
      That's why I added a property in TopLevel so there's still one canonical
      source and things can't get out of sync.
      BUG: 384765
      Test Plan:
      Crystal clear breeze and oxygen decos on my @2x display
      Drag windows to attached @1x display, things still look OK when across 2
      Changing the scale of a screen updated the decos instantly
      Reviewers: #plasma, graesslin
      Reviewed By: #plasma, gr...
  9. 30 Oct, 2017 1 commit
    • David Edmundson's avatar
      Scaled decorations in QPainter mode · 7e6721ec
      David Edmundson authored
      Under wayland we support high DPI putting by putting a separation
      between the logical co-ordinate system and the resolution of rendered
      I didn't include window decorations in the previous wayland scaling
      patchset. They were drawn them at a standard resolution, which is
      implicitly scaled up.
      This uses the Qt scaling, meaning oxygen and breeze (and others) get
      perfect high DPI support with zero client changes.
      Like the window scaling this handles any combination of a 2x scaled
      decoration being rendered on a 1x screen or vice versa.
      CCBUG: 384765
      Test Plan:
      export KWIN_COMPOSE=Q
      Had two screens of different scales
      It was the right size on both (as before)
      Was super-sharp on the fancy screen
      Reviewers: #plasma, hetzenecker, graesslin
      Reviewed By: #plasma, graesslin
      Subscribers: ngraham, graesslin, plasma-devel, kwin, #kwin
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D8504
  10. 01 Sep, 2017 2 commits
    • Martin Flöser's avatar
      Move QPainter compositor into plugin · 535b1079
      Martin Flöser authored
      This change is similar to D7232 and moves the scene_qpainter into a
      dedicated plugin. Compared to the XRender case it's more complicated as
      the platform plugins need to implement a platform specific backend.
      The base implementation for this part used to be in scene_qpainter. As
      the idea is to completly move it away from KWin core it would be point
      less to still have the backend definition in KWin core, but it cannot
      be in the scene plugin as otherwise all platforms need to link the
      To solve this a new platformsupport subdirectory is added which contains
      the scene platform backend as a static library. For the OpenGL scene such
      a static library will also be required.
      Test Plan: SceneQPainter test still passes, nested compositor still works
      Reviewers: #kwin, #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D7259
    • Martin Flöser's avatar
      Provide a virtual Scene::qpainterRenderBuffer() -> QImage* method · c398db3c
      Martin Flöser authored
      Needed by testing of QPainter scene to access the back buffer. Exposed
      as a virtual method in Scene, so that the test does not have to cast to
  11. 09 Aug, 2017 1 commit
    • Martin Flöser's avatar
      Add virtual Scene::scenePainter method · ad4a3107
      Martin Flöser authored
      So far EffectsHandlerImpl directly accessed SceneQPainter::painter
      through a dynamic cast. If in future the QPainter based compositor should
      be moved into a plugin we cannot access it through a dynamic cast.
      To solve this problem the painter method is moved into Scene as
      a virtual method returning a sane default value.
      Reviewers: #kwin, #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D7214
  12. 02 Aug, 2017 1 commit
  13. 29 Mar, 2017 2 commits
  14. 14 Sep, 2016 1 commit
    • Martin Flöser's avatar
      Make WindowPixmap::isValid virtual and override in concrete implementation · 0bb1f2e7
      Martin Flöser authored
      If a buffer gets destroyed the texture created from it is still valid.
      In such a situation the OpenGLWindowPixmap should return true for isValid
      and not false as it did. Similar in QPainter compositor the pixmap is
      valid if there is an image copied from the buffer.
      This change ensures that for example minimizing an XWayland window
      still has a texture during the minimize animation.
      BUG: 368440
      Test Plan:
      Minimize animation plays for X windows and minimized windows
      are shown in present windows.
      Reviewers: #kwin, #plasma_on_wayland
      Subscribers: plasma-devel, kwin
      Tags: #plasma_on_wayland, #kwin
      Differential Revision: https://phabricator.kde.org/D2724
  15. 23 Aug, 2016 1 commit
  16. 01 Jul, 2016 1 commit
    • Martin Flöser's avatar
      [autotests] Add a new test case which can verify the rendering of QPainter Scene · 055e2b3b
      Martin Flöser authored
      The idea behind this autotest is inspired by bug 356328 which produced
      incorrect rendering results. Also it's inspired by openQA which performs
      image reference comparisons.
      This test case tries to go further. It creates reference images which
      must match the rendering result exactly. So far the test case verifies
      the start condition - kwin started and one frame is rendered with default
      cursor in the middle of the screen. And it verifies the moving of the
      cursor without any windows shown. Whenever the cursor moves a repaint
      should be triggered and the old and new area should be properly
      To support this the test needs some minor changes in KWin:
      * Scene provides a frameRendered signal - needed for waiting on frame
      * Scene and SceneQPainter are exported
      * SceneQPainter provides access to it's Backend, so that we get to the
      * ScriptedEffectLoader is exported for getting a list of all scripted
       effects - (we don't want fade to manipulate the rendering)
      Reviewers: #kwin, #plasma_on_wayland
      Subscribers: plasma-devel, kwin
      Tags: #plasma_on_wayland, #kwin
      Differential Revision: https://phabricator.kde.org/D2046
  17. 29 Jun, 2016 3 commits
    • Martin Flöser's avatar
      Paint the software cursor directly in SceneQPainter · 758d41d6
      Martin Flöser authored
      No need to delegate the painting of the software cursor into the backend.
      The core has enough information to perform the rendering itself.
      This change means less code duplication and all platforms which might use
      a software cursor in QPainter compositor gain support for it without any
      further adjustments.
      Reviewers: #kwin, #plasma_on_wayland
      Subscribers: plasma-devel, kwin
      Tags: #plasma_on_wayland, #kwin
      Differential Revision: https://phabricator.kde.org/D2028
    • Martin Flöser's avatar
      Render cursor in multi-screen setup in QPainter Compositor · 23fb02cc
      Martin Flöser authored
      The call to render the cursor was missing in the multi-screen code path
      of the QPainter Compositor.
      Reviewers: #kwin, #plasma_on_wayland
      Subscribers: plasma-devel, kwin
      Tags: #plasma_on_wayland, #kwin
      Differential Revision: https://phabricator.kde.org/D2027
    • Martin Flöser's avatar
      Properly clip the damage region and windows in SceneQPainter · fd19db0f
      Martin Flöser authored
      On the framebuffer backend the software rendered cursor was creating
      rendering artifacts due to incorrect clipping. This change ensures that
      in a single screen setup the clipping is performed correctly. For multi
      screen a similar change might be required, but we currently don't have
      any a way to test that as framebuffer only supports one screen and other
      (visual) platforms don't support the software cursor.
      CCBUG: 356328
      Reviewers: #kwin, #plasma_on_wayland
      Subscribers: plasma-devel, kwin
      Tags: #plasma_on_wayland, #kwin
      Differential Revision: https://phabricator.kde.org/D2024
  18. 15 Apr, 2016 1 commit
  19. 07 Apr, 2016 4 commits
  20. 21 Mar, 2016 1 commit
    • Martin Flöser's avatar
      Drop xcb-shm usage from QPainterWindowPixmap · 6e18cae4
      Martin Flöser authored
      Before we were able to render Xwayland windows through the Wayland buffer
      we used a xcb-shm to map the window data in the QPainter compositor.
      As we don't use that any more and QPainter is not available for X11
      anyway we can just drop the code.
      Reviewers: #plasma
      Subscribers: plasma-devel
      Projects: #plasma
      Differential Revision: https://phabricator.kde.org/D1193
  21. 18 Dec, 2015 3 commits
  22. 12 Aug, 2015 1 commit
  23. 05 May, 2015 5 commits
  24. 24 Apr, 2015 4 commits