Carl Engh

Multiple UI processes with Qt Wayland – A summary

Published Wednesday May 31st, 2017
8 Comments on Multiple UI processes with Qt Wayland – A summary
Posted in Automotive, Biz Circuit & Dev Loop, Embedded, UI, Wayland

Creating multi-process UIs is a requirement for a broad range of systems across many industries, and there are a variety of use cases available. Everything from fully leveraging your hardware in a digital automotive cockpit — unifying the user experience across all screens on a single SoC, through to separating out critical safety features in medical devices and ensuring safe third-party updates for set-top boxes and digital TVs. Qt Wayland helps you create multi-process user interfaces which support complex architectures.

Recently, we have put a lot of effort into Qt Wayland and the purpose of this blog is to provide a summary of all the content pieces that have been created in recent times. We hope this may entice your interest to add a window compositing system in your next project.

Multi-screen demo for Automotive

At Embedded World 2017 one of our showcases was a multi-screen demo featuring a digital instrument cluster and infotainment system (IVI). To create the multi-process architecture, it uses the application manager based on Qt Wayland in the Qt Automotive Suite. This demo gives you a good idea of how a system with multiple UI processes can look.

Qt Wayland for Agriculture with CLAAS E-Systems

CLAAS E-Systems, part of the CLAAS Group, which is one of the leading manufacturers of harvesters and tractors, quickly adopted Qt Wayland. We have been in contact with Andreas Cord-Landwehr from CLAAS, who stressed that the complexity for automotive was nothing compared to the complexity that he experiences within the field of agriculture. He was more than willing to write a blog to tell his story of how Qt Wayland allowed them to improve their UIs and UX for their machinery. Read the blog to learn more about his experiences with Qt Wayland. 

Creating devices with multiple UI processes using Wayland

One of our main developers for Qt Wayland, Johan Helsing, wrote a blog post in conjunction with our release of the Qt Wayland Compositor API in 5.8, where he explained some of the benefits of creating multi-process user interfaces, as well as why and how it can support your project. He also created a video tutorial on how to create a compositor. Read the blog and watch the tutorial and also check out his on-demand webinar — Creating Devices with multiple UI processes.

Qt from git on the Tinkerboard (with Wayland)

Laszlo Agocs, one of our senior software engineers, conducted a test using an Asus Tinkerboard and set up the latest Qt base and qtdeclarative from the dev branch and tested out Qt Wayland for window compositing. Read more about the project and the results.

There are also more blog posts on this topic available. Contact us if you need support or consulting on how to get started.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Automotive, Biz Circuit & Dev Loop, Embedded, UI, Wayland


Reza says:

Thanks a lot for this great effort, Is Qt Wayland implemented and runs on all platforms specifically Windows?

Lilian says:

Wayland does not run on Windows, therefore Qt Wayland can’t use it.
Windows has its own display server.

You can find more info about Wayland on the official website:

Johan Helsing Johan Helsing says:

Wayland is designed as Linux technology, so in principle it only makes sense there. However, there are some patches up for review that intend to make QtWayland work on macOS for development purposes, but I think it’s unlikely that anything will happen on Windows any time soon due to how different the platforms are.

In released Qt versions, Wayland only runs on Linux. This is a Wayland limitation, and not a Qt issue.

Laci says:

I’l like to use QtWayland, and I made a test with it. I have an i.MX6Q board, I tested QtWayland Compositor 5.8 with that.
This board supports HW accelerated OpenGL ES3 with wayland backend, and it worked good. The spinning cubes, animals were smooth, no hitching at all. But when I ran the benchmark client named glmark2-es2-wayland , I got the following results (higher is better):
Original Weston Compositor : score 254
QtWayland Compositor C++ : score 110
QtWayland Compositor QML : score 75
On X11 server glmark2-es2 : score 194
As you can see QtWayland Compositor’s (qt5 wayland demo) speed is about half of X11, although Wayland is supposed to be faster than X11, as Weston proves this. I think that besides of features, (QtWayland Compositor class looks much better option for a programmer, than libwayland) the speed is a primary importance at a graphics server in embedded world. I asked this question in 2 Qt5 blogs, I got no answer at all. Can we expect any improvement with QtWayland Compositor in the future, or this is what we have ?

Johan Helsing Johan Helsing says:

glmark-es2 is a program that will try to render frames as fast as possible, regardless of how fast the compositor is actually able to show them. This means most of the frames are wasted, and never shown on the screen. Weston is scoring higher than the Qt compositors because it’s able to hand back the unused buffers much faster.

In applications that synchronize with the compositor before drawing the next frame—this is the usual behavior—the difference is less significant.

We are, however, seeing a small difference, even at more normal frame rates, and we’re looking into the issue.

Laci says:

Thanks Johan, that sounds great, please look into this, because QtWayland would be very lovely anyway. Of course I know that most of frames will be wasted, actually the display’s vertical frequency is the barrier, but still such a benchmark precisely shows and compares the graphical system’s performance. You can’t see the difference if your FPS would be higher, because its limited to vsync. But when its lower, than the half performance means half FPS indeed. I can accept if the QML Wayland server is slower, but the C++ one should be very similar to Weston in my opinion. You just forgot to optimize it till now at least I guess so. This is not a problem on a desktop PC with powerful nVidia or AMD graphic cards, but only on embedded boards with much weaker GPU. A Wayland compositor should always be faster than an X11 server, thats the point, thats why we want to move to Wayland. If its not, if its significantly slower, thats a big problem, than we have to think it twice if we use it or not.

Johan Helsing Johan Helsing says:

Just beware that glmark-es2 can be misleading with regards to actual performance, though.

I just ran glmark-es2 on an IMX6 embedded device running Weston. And while many of the tests showed frame rates of 700 or above, the actual frame rate on screen never exceeded 38 fps. Even one of the simplest Weston test programs, weston-simple-egl, couldn’t achieve more than 38 (it’s waiting for frame events from the compositor before submitting new frames). On one hand, this makes me suspect that something might be wrong with Weston in my setup, but on the other, it does illustrate the fact that a high glmark score is possible even on a broken or underperforming compositor.

When I ran glmark-es2 on Qt Wayland compositors, the client was shown at a steady 60 fps, but the tests results were lower than on Weston. What I saw, was that the frame rate seemed to be capped at 120 fps, which means that for some reason, Qt Wayland is holding on to the unused buffers for too long.

In the more demanding glmark-es2 tests (refract, ideas, desktop, effect2d) that ran at around 30-60 fps on Weston, I got almost the exact same results on Qt Wayland.

Laci says:

Hi Johan,
Thanks for the answer. I think this is not the good place to discuss about technical details, it just ruins the post if we start to talk about bugs and errors. Carl is not happy. Could you tell me any qt blog or forum where I can tell you everything what I experienced, and how did I test QtCompositor ?

Commenting closed.

Get started today with Qt Download now