D24215: [libkwineffects] Introduce API to easily show a QtQuick scene in an effect

David Edmundson noreply at phabricator.kde.org
Wed Sep 25 11:32:36 BST 2019


davidedmundson created this revision.
davidedmundson added a reviewer: KWin.
Herald added a project: KWin.
Herald added a subscriber: kwin.
davidedmundson requested review of this revision.

REVISION SUMMARY
  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.
  
  Notes:
  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

REPOSITORY
  R108 KWin

BRANCH
  effectview_new

REVISION DETAIL
  https://phabricator.kde.org/D24215

AFFECTED FILES
  autotests/mock_effectshandler.h
  effects.cpp
  effects.h
  libkwineffects/CMakeLists.txt
  libkwineffects/kwineffectquickview.cpp
  libkwineffects/kwineffectquickview.h
  libkwineffects/kwineffects.h
  platformsupport/scenes/opengl/abstract_egl_backend.cpp
  plugins/platforms/x11/standalone/CMakeLists.txt
  plugins/platforms/x11/standalone/glxbackend.cpp
  plugins/scenes/opengl/scene_opengl.cpp
  plugins/scenes/opengl/scene_opengl.h
  plugins/scenes/qpainter/scene_qpainter.cpp
  plugins/scenes/qpainter/scene_qpainter.h
  plugins/scenes/xrender/scene_xrender.cpp
  plugins/scenes/xrender/scene_xrender.h
  scene.h

To: davidedmundson, #kwin
Cc: kwin, LeGast00n, The-Feren-OS-Dev, sbergeron, jraleigh, fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwin/attachments/20190925/c713fc02/attachment-0001.html>


More information about the kwin mailing list