https://bugs.kde.org/show_bug.cgi?id=295775

--- Comment #2 from Vlad Zahorodnii <vlad.zahorod...@kde.org> ---
(In reply to David Edmundson from comment #1)
>  - Add a QQuickItem subclass that has a window as a texture.
I personally would prefer this option because it means we won't have to make
unnecessary copies of client buffers. In many cases, we don't need to render
every window in an offscreen texture. QtQuick has the best knowledge of the
scene, so it makes sense to let it decide whether to render the window in an
offscreen texture.

However, the sharing of scene textures with QtQuick raises several issues:

(a) We will have to share scene textures between OpenGL contexts

(b) In addition to sharing OpenGL textures, we will also have to share client
buffers

The problem (a) is a bit problematic on X11, but I think it's not a big issue
on Wayland. Given that the API of the WindowThumbnail is super minimalistic, we
could maintain both thumbnail implementations for the time being and switch
between two at runtime, e.g. if it's wayland, use the new thumbnails
implementation, otherwise fallback to the old one.

In order to fix problem (b) we need to refactor buffer management code in KWin.
Ideally, we need a client buffer and perhaps(?) an integration/a factory class
for those buffers (for better encapsulation), e.g.

  class ClientBuffer : public QObject
  {
      Q_OBJECT

  public:
      virtual bool isValid() const;
      virtual bool isDirty() const;

      virtual bool create();
      virtual void update();

      virtual QRegion damage() const;
      virtual QRegion shape() const;
      virtual QRect rect() const;
      virtual qreal scale() const;
      virtual bool haveAlphaChannel() const;

      virtual Toplevel *toplevel() const;

      virtual QOpenGLTexture *toOpenGLTexture() const;
      virtual QImage toImage() const;
      // virtual vkImage toVulkanImage() const;

  Q_SIGNALS:
      void lost(); // or something
  };

Once we have a client buffer abstraction in kwin, sharing client buffers
between the opengl scene and qt quick will be straightforward to implement.

The introduction of the ClientBuffer class would require a ground up rework,
but I think it's going to be worth the effort because we need to move damage
tracking from Toplevel to ClientBuffer to properly handle sub-surfaces on
Wayland. We also need the ClientBuffer for the opaque-ness stuff in the scene.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to