Hi Markus, If you are running this nested inside an X session (and comparing nested Weston vs nested QtWayland), you have to be careful to set the right environment variables (info in QtWayland readme), or QtWayland will fall back to using software buffers. Also, if you're running it inside a gnome wayland session, you will probably still get the X backend of the QtWayland compositor because we have blacklisted gnome and fall back to XWayland.
Even better would be to run the compositor with the eglfs backend instead of nesting it, and comparing that against weston's drm backend. Unless you're doing this already, then there is not supposed to be a noticeable performance gap with QtWayland compositors compared to Weston. So if that's the case, please file a bug for it. Br, Johan Helsing ________________________________ From: Interest <interest-boun...@qt-project.org> on behalf of Gramer, Markus <markus.gra...@b1-es.com> Sent: Monday, October 21, 2019 16:34 To: interest@qt-project.org <interest@qt-project.org> Subject: [Interest] QtWayland compositors lagging Hi there, I was wondering if anyone on this list has experience with Wayland compositors. I am working on a project, that requires two processes (on an embedded Linux system) to be displayed at the same time. We thus chose to use a Wayland compositor based on the minimal-qml example of QtWayland. However, we now noticed that the sliders in the application exhibit a serious lag. We were able to reproduce this effect with a minimum example running within our Wayland compositor in an Ubuntu VM on my host computer. The example application consists of a single slider (QtQuick.Conntrols 2.12) and a simple infinite animation (to measure rendering performance). With the same application running in the Weston compositor, the lag was not noticeable. We also tested the application with other QtWayland compositor examples, and always observed the lag. I am now wondering if this issue is inherent to QtWayland or if I would be able to modify some configuration to achieve a similar performance than Weston does. Since the use case should be rather common, I would expect other people to have encountered/solved similar issues. I would be grateful for anyone sharing their experience. Kind regards, Markus Gramer For completeness our current compositor implementation: Default main.cpp: #include <QtCore/QUrl> #include <QtCore/QDebug> #include <QtGui/QGuiApplication> #include <QtQml/QQmlApplicationEngine> int main(int argc, char *argv[]) { QCoreApplication::setAttribute(Qt::AA_ShareOpenGLContexts, true); QGuiApplication app(argc, argv); QQmlApplicationEngine appEngine(QUrl("qrc:///qml/main.qml")); return app.exec(); } main.qml: import QtQuick 2.0 import QtQuick.Window 2.12 import QtWayland.Compositor<http://QtWayland.Compositor> 1.3 WaylandCompositor { id: waylandCompositor property int cIviIdMain: 1 property int cIviIdActuator: 2 WaylandOutput { sizeFollowsWindow: true window: Window { id: waylandWindow width: 1920 height: 1080 visible: true property int secondHeight: 200 Rectangle { id: mainArea width: parent.width height: parent.height - waylandWindow.secondHeight anchors.left: parent.left color: "#434345" Text { anchors.centerIn: parent color: "#F3F4F6" text: "Main Area" } } Rectangle { id: secondArea width: parent.width height: waylandWindow.secondHeight anchors.top: mainArea.bottom color: "#828282" Text { anchors.centerIn: parent color: "#F3F4F6" text: "Secondary Area" } } } } Component { id: shellComponent ShellSurfaceItem { anchors.fill: parent onSurfaceDestroyed: destroy() onWidthChanged: handleResized() onHeightChanged: handleResized() function handleResized() { shellSurface.sendConfigure(Qt.size(width, height)); } } } // Extensions are additions to the core Wayland // protocol. IviApplication { onIviSurfaceCreated: { //shellSurfaces.append({shellSurface: iviSurface}) var surfaceArea switch (iviSurface.iviId) { case waylandCompositor.cIviIdMain: surfaceArea = mainArea break; case waylandCompositor.cIviIdActuator: surfaceArea = secondArea break; } var item = shellComponent.createObject(surfaceArea, { "shellSurface": iviSurface } ); item.handleResized(); } } } _________________________________________ Dr. Markus Gramer ● Design Engineer Software phone: +49 (89) 215 478 489 ● skype/email: markus.gra...@b1-es.com<mailto:markus.gra...@b1-es.com> b1 Embedded Solutions Canada Inc ● 161 Mistysugar Trail ● Thornhill ON L4J 8T4 ● Canada ● www.b1-es.com<http://www.b1-es.com/> [cid:image001.jpg@01D38578.D79B8660][cid:79ED2F0E3257B046933C95EC51AC626F@b1-es.com]
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest