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