Thank you.

Currently, my approach is to use a for loop to call 
QQuickWindow::setRenderTarget to change the rendering target while change the 
projectionMatrix of QSGRenderer.

"because different screens have different surface formats requirements"

Is point say a QSurfaceFormat? QSurface::format()? Does QRhi depend on it? I do 
not find many using in QRhi, have some using in QRhiGles2::create.

"I know there have been talks of decoupling the Qt Quick graph from the window"

How to read those talks?
________________________________
From: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfe...@qt.io>
Sent: Monday, July 10, 2023 17:38
To: JiDe Zhang <zc...@live.com>; Qt邮件列表 <development@qt-project.org>
Subject: Re: QtWayland compositor can't to render a wl_surface to multi 
outputs, Is this a restrict of QtQuick graphics scene?

Hi,

Each window has an isolated scene graph and RHI instance, which is the reason 
for this limitation if I understand correctly. Decoupling them is actually 
quite complicated, because different screens have different surface formats 
requirements and it might not be possible to render to both screen within the 
same context or to share graphics resources between them. These difficulties 
are also why Wayland Compositor bases outputs on windows with isolated 
graphics. I know there have been talks of decoupling the Qt Quick graph from 
the window, so that the same Qt Quick code can control items in multiple 
windows. There would still be separate graphics for the two windows and then 
need for duplicate items, but synchronizing animations in that case should be 
easier. Nothing concrete has come of this yet, though, but to me it sounds like 
a more feasible way forwards than redesigning the Qt Quick scene graph.

In the current state, duplicating the items is the correct way to go, at least. 
In order to make sure the animations are in sync, you could for instance have 
some centralized property in a singleton which is read from both scenes and 
just animate that. I think that's probably the easiest way.


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

________________________________
From: Development <development-boun...@qt-project.org> on behalf of JiDe Zhang 
<zc...@live.com>
Sent: Tuesday, July 4, 2023 9:06 AM
To: Qt邮件列表 <development@qt-project.org>
Subject: [Development] QtWayland compositor can't to render a wl_surface to 
multi outputs, Is this a restrict of QtQuick graphics scene?

The following is a part of an QtWayland example:

WaylandOutput {
        sizeFollowsWindow: true
        window: Window {
            width: 1024
            height: 768
            visible: true

            Repeater {
                model: shellSurfaces

                ShellSurfaceItem {
                    shellSurface: modelData
                    onSurfaceDestroyed: shellSurfaces.remove(index)
                }
            }
        }
}


If I have two displays, and a part of a ShellSurfaceItem is in the first 
display, and the other part of the ShellSurfaceItem in the second display. In 
this case, I need to ensure the user can see this ShellSurfaceItem
on both first and second displays, on QtWayland, I can using two WaylandOutput 
with two Window for this case, and create ShellSurfaceItem for which 
WaylandOutput.

But, If I using two ShellSurfaceItem for one wl_surface, I can't sync the 
window animation in different WaylandOutput, this is a hard job, because the 
QQuickItem must bind to single Window, it's can't render to multi Windows.

The better way is redesign QtQuick scene graphics, like as:


  1.  Add QQuickScene class to instead of a part of functions of QQuickWindow. 
a QQuickItem must be added to a QQuickScene, a QQuickScene is a coordinate 
system.
  2.  Add QQuickViewport class, and allow attach multi QQuickViewport to one 
QQuickScene. the QQuickViewport be responsible for render QQuickItem to target 
output. And allow the QQuickViewport can render in a new thread(be different 
than the other QQuickViewport in same QQuickScene).
  3.  Add QQuickRenderTarget::fromSurface(EGLSurface/VkSurface) functions, and 
using QQuickRenderTarget to QQuickViewport::render(QQuickRenderTarget target).
  4.  The QQuickWindow don't depends on QSG* class, it can wapper 
QQuickViewport and QQuickRenderTarget to render QQuickItem.
  5.  Add QQuickSceneHelper abstract class, The QQuickWindow event dispense to 
QQuickSceneHelper, and QQuickSceneHelper dispense event to QuickItem. Provide 
like as "virtual QQuickSceneHelper::setCursor" functions to instead of 
QQuickWindow::setCursor in QQuickItem::setCursor.
  6.  The QQuickItem without QQuickWindow, using QQuickItem::pixelRatio to 
instead of QQuickWindow::effectiveDevicePixelRatio(), the 
QQuickItem::pixelRatio is only using for load resources(like as 
QQuickImage::load), for the render matrix, using the 
QQuickViewport::devicePixelRatio when rendeing.

The above changes may not change the abi.

If I misunderstand QtWayalnd and QtQuick Scene Graphics, please tell me, thanks.


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to