[Interest] QtWayland compositors lagging

[Johan Helsing]

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-bounces at qt-project.org> on behalf of Gramer, Markus <Markus.Gramer at b1-es.com>
Sent: Monday, October 21, 2019 16:34
To: interest at qt-project.org <interest at 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.gramer at b1-es.com<mailto:markus.gramer at 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 at 01D38578.D79B8660][cid:79ED2F0E3257B046933C95EC51AC626F at b1-es.com]




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20191022/15e9b786/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture (Device Independent Bitmap) 1.jpg
Type: image/jpeg
Size: 3115 bytes
Desc: Picture (Device Independent Bitmap) 1.jpg
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20191022/15e9b786/attachment.jpg>