Qt Creator 4.4 Beta released

We are happy to announce the release of Qt Creator 4.4 Beta!



This version of Qt Creator features optional inline annotations for warnings and errors from the Clang code model and for bookmark comments (Options > Text Editor > Display > Display annotation behind lines). This way, you can easily see the details of issues while you type, without the need to hover your mouse over underlined text or the marker on the left side.


When you rename a symbol, you are now offered to also rename files with the same name. Just trigger the renaming and check “Rename N files” (where “N” will be the number of files with the same base name) in the search results panel before pressing the actual “Replace” button.

If you have the Clang code model enabled, this is now also used for the highlighting of the identifier at the text cursor, which was previously still using the built-in model in any case.

There have been many bug fixes as well. C++ and Qt keywords are no longer wrongly considered keywords in C files, the function signature hint will now work when completing constructors with the Clang code model, and many more.


We were pretty busy fixing issues already in the 4.3 line of Qt Creator, but there are some improvements in 4.4 as well. We added a filter to the CMake variables setting in build configurations, fixed that headers from the top level directory were not shown in the project tree when using server-mode and improved the handling of CMAKE_RUNTIME_OUTPUT_DIRECTORY in CMake project files.

Other changes

We removed the non-maintained support for Window CE, and changed the ClearCase integration to be disabled by default.

This is just a small selection of the changes and improvements done in 4.4. Please have a look at our change log for a more detailed overview.

Known Issues

QML Profiler can currently get into invalid state. Stopping the application before stopping profiling currently does not work.

Get Qt Creator 4.4 Beta

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.4 Beta released appeared first on Qt Blog.

New in Qt 5.10: recursive filtering for QSortFilterProxyModel

When using Qt’s model/view framework, filtering has always been very easy with QSortFilterProxyModel. To filter a list using text typed by the user in a line-edit, you have certainly been applying the standard recipe:

  1. instantiate the proxy;
  2. insert it between view and source model;
  3. connect the lineedit’s textChanged signal to the proxy’s setFilterFixedString slot; done!

But what if the model is a tree rather than a flat list?

Let’s use the tree below as an example. As you can …

The post New in Qt 5.10: recursive filtering for QSortFilterProxyModel appeared first on KDAB.

QML vs. C++ for application startup time

After 5.8 reduced startup times with its QML compilation caching, object creation remains one of the largest startup time consumer for Qt Quick applications. One can use Loaders to avoid loading parts of the application that are not currently visible, but some scenes with higher complexity can still be taking quite some time to initialize when they urgently need to be displayed, especially on embedded systems.

At QtCon 2016 Andrew Knight presented a few benchmarks showing a situations where C++ can improve Qt Quick object creation times over QML. A conclusion of the session was that those benchmark results would need to be taken with a grain of salt since the specific benefits could be smaller in a real application relatively to everything else happening around.

What we’re presenting today are results of converting parts of a well-known QML example to C++ using public and private APIs, measuring the improvements on loading and execution times to have a better estimate of the opportunity for real world applications.


We’re going to use the samegame QML example as reference. This gives us a complete application handling events and producing visual outputs. Like many QML applications reaching initial maturity, focus hasn’t been put on performance optimizations in samegame yet.

Let's start by profiling the application in order to fix the low hanging fruits first. This involves the QML Profiler, but also a regular C++ profiler (like macOS Instruments or Linux perf) together with a "-release -force-debug-info" configured Qt (don't pass -developer-build since it changes the way QML caching behaves). This leads us to remove Qt Quick Particles, QQmlFileSelector, and we’ll also convert property behaviors and states into imperative animations. These changes already considerably improve the performances by reducing the number of QObjects in the scene and by preventing the use of a few less scalable features of Qt Quick.

Most importantly for now, this allows us to focus performance measurements on application code, making sure that both our QML and C++ implementations use the same Qt Quick code paths and total number of QObjects.


Samegame will be launched in fullscreen when using the eglfs platform plugin, this means that the game area will fill the screen, and on a 1080p display will give us a grid of 60x31 game blocks. We use a Nitrogen6X quad core i.MX6 for this project, running Yocto 2.2 and a standard cross-compiled build of Qt 5.9.1. Running those benchmarks on desktop gave us times around 20x faster, but the relative improvements were similar so we'll focus on i.MX6 results.

Two actions in the application will be uses as reference for our benchmarks:

  • Starting a new game, which uses a thin JavaScript loop to fill the game area with created Block objects.
  • Clicking at a fixed position inside the game area, which is a heavier JavaScript loop that updates the position of all blocks on the right of the clicked column (since the game has been hardcoded to fill each column with the same color, clicking removes one column and move following columns to the left)

The StartGameBenchmark measures creating this scene, the HandleClickBenchmark measures clicking on the left-most row and iterating over all blocks to move them left.

A benchmark has been written inside main() to wrap those functions and execute them multiple times to be able to provide more precise measurements. At multiple stages of the conversion from QML to C++ we will run those two benchmarks and gather results:

  1. The reference QML implementation (with Qt Quick Particles, QQmlFileSelector and declarative animations removed) without any C++:

    // QML
    Block { function fadeIn() { /*...*/ } }
    // JavaScript
  2. Only the samegame.js JavaScript Logic code that is run through our benchmarks has been converted to C++:

    // QML
    Block { function fadeIn() { /*...*/ } }
    // C++
    QMetaObject::invokeMethod(block, "fadeIn");
  3. Block.qml is also implemented in C++ as a QQuickItem subclass. Everything is still connected together using Qt meta-object properties and methods:

    // C++
    class Block : public QQuickItem { Q_INVOKABLE void fadeIn() { /*...*/ } };
    // C++
    QMetaObject::invokeMethod(block, "fadeIn");
  4. As above, but doing direct C++ method calls rather than going through meta-objects:

    // C++
    class Block : public QQuickItem { void fadeIn() { /*...*/ } };
    // C++

Benchmark 1: Starting a new game

Our implementation is using 5 QObjects per block, 2 of which are QQuickItems, for a total of 9300 QObjects. Creating a screen full of blocks for a new game takes 1.153 seconds on our i.MX6 (definitely user-noticeable), but we can reduce it to 0.388 seconds if we create the same item and object structure in C++ (197% faster). The largest gain comes from reimplementing Block.qml in C++ which alone gives us a speed improvement of 124%, mostly because we avoid the evaluation of QML properties and the creation of property bindings during instantiation.

Benchmark 2: Handling a click

This benchmark iterates over the blocks that need to be moved, starts an animation on the x and y property of each block’s root item, and update the blocks board position in the index array. Our C++ implementation is 120% faster but since this action doesn’t create any new QML object, the largest gain comes from reimplementing the JavaScript for-loop in C++, which alone is 57% faster.

The QML JIT implementation usually competes acceptably well with C++ and one thing to note is that the total time for handling this click in our case also has a considerably smaller performance footprint on our application than creation times covered by the Start Game benchmark. So while relatively put this is faster, the user will not notice the 117 ms reduction for Handle Click as much as the 764 ms reduction of the Start Game case.

Why is C++ faster?

Qt Quick and QML are very efficient when it comes to update a scene frame after frame to produce a smooth animation. Properties are consistently and efficiently updated according to animations by property bindings, layout will involve only the necessary elements and the scene graph will reuse as many OpenGL objects as possible to render the new frame, most of the time, with optimal state changes in system and graphics memory.

However, having this structure in place requires some runtime initialization to be done at creation time, and a mostly-dynamically-typed language like QML can’t really compete in this sport with a language like C++, whose design makes performance and compile-time optimizations a top-priority over its other language characteristics.
On top of having to create the same backing C++ QObject and QQuickItem, QML must resolve dynamic types, create data-structures to represent property bindings and go through the Qt meta-object type system to access any native member. Almost all of which C++ performs equivalently at compile time.

One of the reasons why QML can choose to offer conciseness and development speed at the cost of some performance is because it’s also designed to interface well with C++ code. This is an opportunity that, for example, Qt Quick Controls 2 has taken to reduce compilation and creation times with gains comparable to what is presented here. Qt Quick Controls 2 has an advantage over applications though: it’s part of Qt and it has access to private symbols like QQuickText, QQuickRectangle, QQuickFlickable, and even QQuickItemPrivate.

While our C++ implementation is tailored for measuring the potential performance gain of those two specific benchmarks, an ideal method would be if applications could do layout in QML, but handle events and state changes from C++ where the performance gain would be valuable. This could take advantage of strengths of both languages while reducing the number of dynamically-typed property bindings and JavaScript blocks to perform at runtime.
There is still some work to be done in Qt Quick to be able to conveniently harness C++ in UI code. We've already been able to mix the two languages using some hacks for this exercise, but the real blocker at the moment is that we need to be able to create Qt Quick visual primitives like animations, images and rectangles from C++ just like from QML.

Give up binary compatibility?

For this experiment, we had to expose private API that isn’t dynamically exported (i.e. QQuickSpringAnimation). qmake makes it relatively easy to access exported private symbols. This comes at a hefty price: those APIs are not supported and source and binary compatibility are not guaranteed.
An application could theoretically use private APIs without major problems if they are recompiled for any update of Qt. Changes to Qt private API would otherwise likely result in application crashes.

The question is then: should more of the Qt Quick API be publically exposed to C++ application code?


While we demonstrate how using some C++ private Qt Quick APIs can allow you to improve the creation times today, this is unsupported it’s not something that we recommend.

This blog post puts emphasis on creation times, but note that for general performance optimizations we recommend profiling and following the excellent Qt Quick Performance Considerations And Suggestions before considering any unsupported solution.

It should be clear that even though C++ is faster in this case, declarative QML will usually remain a better choice for core UI code because of its flexibility and conciseness. QML is also getting faster every release, this gap will continue shrinking up to a point. As for non-UI business logic, C++ can already be used comfortably without requiring using private Qt Quick APIs.

Long creation times are also not a problem if it can happen while the user is not waiting, this can be accomplished with asynchronous Loaders or by pre-loading components.

To conclude we are asking the community: Are those loading time improvements a great enough opportunity to justify improving the C++ brigde for UI code and extending the public Qt Quick API to classes like animations, QQuickRectangle and QQuickImage? A set of base classes that would give applications a freedom similar to what Qt Quick Controls 2 has.

Contribute to the discussion by letting us know in social medias or comments below if you have experience using C++ for Qt Quick UI code, and/or could benefit from having those functionalities publicly available.

Let There Be Shapes!

One of the new features of the upcoming Qt 5.10 is the introduction of the shapes plugin to Qt Quick. This allows adding stroked and filled paths composed of lines, quadratic curves, cubic curves, and arcs into Qt Quick scenes. While this has always been possible to achieve via QQuickPaintedItem or the Canvas type, the Shape type provides a genuine first-class Qt Quick item that from the scene graph’s perspective is backed by either actual geometry or a vendor-specific GPU accelerated path rendering approach (namely, GL_NV_path_rendering).

The shapes example, running on an Android tablet

Why is This Great?

  • There is no rasterization involved (no QImage, no OpenGL framebuffer object), which is excellent news for those who are looking for shapes spanning a larger area of a possibly high resolution screen, or want to apply potentially animated transformations to the shapes in the scene.
  • The API is fully declarative and every property, including stroke and fill parameters, path element coordinates, control points, etc., can be bound to in QML expressions and can be animated using the usual tools of Qt Quick. Being declarative also means that changing a property leads to recalculating only the affected sets of the underlying data, something that has been traditionally problematic with imperative painting approaches (e.g. QPainter).
  • There are multiple implementations under the hood, with the front Qt Quick item API staying the same. The default, generic solution is to reuse the triangulator from QPainter’s OpenGL backend in QtGui. For NVIDIA GPUs there is an alternative path using the GL_NV_path_rendering OpenGL extension. When using the software renderer of Qt Quick, a simple backend falling back to QPainter will be used. This also leaves the door open to seamlessly adding other path rendering approaches in the future.

Status and Documentation

Right now the feature is merged to the dev branch of qtdeclarative and will be part of 5.10 onces it branches off. The documentation snapshots are online as well:

(due to some minor issues with the documentation system some types in Particles get cross-linked in the Inherited By section and some other places, just ignore this for now)

The canonical example is called shapes and it lives under qtdeclarative/examples/quick as expected.

Let’s See Some Code

Without further ado, let’s look at some code snippets. The path specification reuses existing types from PathView, and should present no surprises. The rest is expected to be fairly self-explanatory. (check the docs above)

1. A simple triangle with animated stroke width and fill color.


Shape {
    id: tri
    anchors.fill: parent

    ShapePath {
        id: tri_sp
        strokeColor: "red"
        strokeWidth: 4
        SequentialAnimation on strokeWidth {
            running: tri.visible
            NumberAnimation { from: 1; to: 20; duration: 2000 }
            NumberAnimation { from: 20; to: 1; duration: 2000 }
        ColorAnimation on fillColor {
            from: "blue"; to: "cyan"; duration: 2000; running: tri.visible

        startX: 10; startY: 10
        PathLine { x: tri.width - 10; y: tri.height - 10 }
        PathLine { x: 10; y: tri.height - 10 }
        PathLine { x: 10; y: 10 }

2. Let’s switch over to dash strokes and disable fill. Unlike with image-backed approaches, applying transformations to shapes are no problem.


Shape {
    id: tri2
    anchors.fill: parent

    ShapePath {
        strokeColor: "red"
        strokeWidth: 4
        strokeStyle: ShapePath.DashLine
        dashPattern: [ 1, 4 ]
        fillColor: "transparent"

        startX: 10; startY: 10
        PathLine { x: tri2.width - 10; y: tri2.height - 10 }
        PathLine { x: 10; y: tri2.height - 10 }
        PathLine { x: 10; y: 10 }

    SequentialAnimation on scale {
        running: tri2.visible
        NumberAnimation { from: 1; to: 4; duration: 2000; easing.type: Easing.InOutBounce }
        NumberAnimation { from: 4; to: 1; duration: 2000; easing.type: Easing.OutBack }

3. Shape comes with full linear gradient support. This works exactly like QLinearGradient in the QPainter world.


Shape {
    id: tri3
    anchors.fill: parent

    ShapePath {
        strokeColor: "transparent"

        fillGradient: LinearGradient {
            x1: 20; y1: 20
            x2: 180; y2: 130
            GradientStop { position: 0; color: "blue" }
            GradientStop { position: 0.2; color: "green" }
            GradientStop { position: 0.4; color: "red" }
            GradientStop { position: 0.6; color: "yellow" }
            GradientStop { position: 1; color: "cyan" }

        startX: 10; startY: 10
        PathLine { x: tri3.width - 10; y: tri3.height - 10 }
        PathLine { x: 10; y: tri3.height - 10 }
        PathLine { x: 10; y: 10 }

    NumberAnimation on rotation {
        from: 0; to: 360; duration: 2000
        running: tri3.visible

4. What about circles and ellipses? Just use two arcs. (note: one ShapePath with two PathArcs is sufficient for a typical circle or ellipse, here there are two ShapePath due to the different fill parameters)


Shape {
    id: circle
    anchors.fill: parent
    property real r: 60

    ShapePath {
        strokeColor: "transparent"
        fillColor: "green"

        startX: circle.width / 2 - circle.r
        startY: circle.height / 2 - circle.r
        PathArc {
            x: circle.width / 2 + circle.r
            y: circle.height / 2 + circle.r
            radiusX: circle.r; radiusY: circle.r
            useLargeArc: true
    ShapePath {
        strokeColor: "transparent"
        fillColor: "red"

        startX: circle.width / 2 + circle.r
        startY: circle.height / 2 + circle.r
        PathArc {
            x: circle.width / 2 - circle.r
            y: circle.height / 2 - circle.r
            radiusX: circle.r; radiusY: circle.r
            useLargeArc: true

5. Speaking of arcs, PathArc is modeled after SVG elliptical arcs. Qt 5.10 introduces one missing property, xAxisRotation.


Repeater {
    model: 2
    Shape {
        anchors.fill: parent

        ShapePath {
            fillColor: "transparent"
            strokeColor: model.index === 0 ? "red" : "blue"
            strokeStyle: ShapePath.DashLine
            strokeWidth: 4

            startX: 50; startY: 100
            PathArc {
                x: 150; y: 100
                radiusX: 50; radiusY: 20
                xAxisRotation: model.index === 0 ? 0 : 45

Repeater {
    model: 2
    Shape {
        anchors.fill: parent

        ShapePath {
            fillColor: "transparent"
            strokeColor: model.index === 0 ? "red" : "blue"

            startX: 50; startY: 100
            PathArc {
                x: 150; y: 100
                radiusX: 50; radiusY: 20
                xAxisRotation: model.index === 0 ? 0 : 45
                direction: PathArc.Counterclockwise

6. Quadratic and cubic Bezier curves work as expected. Below is a quadratic curve with its control point animated.


Shape {
    id: quadCurve
    anchors.fill: parent

    ShapePath {
        strokeWidth: 4
        strokeColor: "black"
        fillGradient: LinearGradient {
            x1: 0; y1: 0; x2: 200; y2: 200
            GradientStop { position: 0; color: "blue" }
            GradientStop { position: 1; color: "green" }

        startX: 50
        startY: 150
        PathQuad {
            x: 150; y: 150
            controlX: quadCurveControlPoint.x; controlY: quadCurveControlPoint.y

Rectangle {
    id: quadCurveControlPoint
    color: "red"
    width: 10
    height: 10
    y: 20
    SequentialAnimation on x {
        loops: Animation.Infinite
        NumberAnimation {
            from: 0
            to: quadCurve.width - quadCurveControlPoint.width
            duration: 5000
        NumberAnimation {
            from: quadCurve.width - quadCurveControlPoint.width
            to: 0
            duration: 5000

7. The usual join and cap styles, that are probably familiar from QPainter and QPen, are available.


Shape {
    anchors.fill: parent

    ShapePath {
        strokeColor: "red"
        strokeWidth: 20
        fillColor: "transparent"
        joinStyle: ShapePath.RoundJoin

        startX: 20; startY: 20
        PathLine { x: 100; y: 100 }
        PathLine { x: 20; y: 150 }
        PathLine { x: 20; y: 20 }

    ShapePath {
        strokeColor: "black"
        strokeWidth: 20
        capStyle: ShapePath.RoundCap

        startX: 150; startY: 20
        PathCubic {
            x: 150; y: 150; control1X: 120; control1Y: 50; control2X: 200
            SequentialAnimation on control2Y {
                loops: Animation.Infinite
                NumberAnimation { from: 0; to: 200; duration: 5000 }
                NumberAnimation { from: 200; to: 0; duration: 5000 }

Any Downsides?

Does this mean the time has finally come to add hundreds of lines and curves and arcs to every Qt Quick scene out there?

Not necessarily.

Please do consider the potential performance implications before designing in a large number of shapes in a user interface. See the notes in the Shape documentation page.

In short, the most obvious gotchas are the following:

  • [generic backend] Shapes with a lot of ShapePath child objects will take longer to generate the geometry. The good news is that this can be mitigated by setting the asynchronous property to true which, as the name suggests, leads to spawning off worker threads without blocking the main UI. This comes at the cost of the shape appearing only after the non-asynchronous UI elements.
  • [GL_NV_path_rendering backend] Geometry generation is a non-issue here, however due to the way the “foreign” rendering commands are integrated with the Qt Quick scene graph, having a large number of Shape items in a scene may not scale very well since, unlike plain geometry-based scenegraph nodes, these involve a larger amount of logic and OpenGL state changes. Note that one Shape with several ShapePath children is not an issue here since that is really just one node in the scenegraph.
  • Antialiasing is currently covered only through multi or super sampling, either for the entire scene or for layers. Note that Qt 5.10 introduces a very handy property here: layer.samples can now be used to enable using multisample renderbuffers, when supported.
  • Shape is not a replacement for rectangles and rounded rectangles provided by Rectangle. Rectangle will always perform better and can provide some level of smoothing even without multisampling enabled.

Nevertheless we expect Shape to be highly useful to a large number of Qt Quick applications. The Qt 5.10 release is due H2 this year, so…stay tuned!

The post Let There Be Shapes! appeared first on Qt Blog.

Qt WebGL Streaming merged

Some time ago I published a couple of blog posts talking about Qt WebGL Streaming plugin. The time has come, and the plugin is finally merged into the Qt repository. In the meantime, I worked on stabilization, performance and reducing the calls sent over the network. It also changed a bit in the way the connections are handled.

New client approach

In the previous implementations, the client was accepting more than one concurrent connections. After the latest changes, the plugin is going to behave like a standard QPA plugin. Now, only one user per process is allowed. If another user tries to connect to the web server, it will see a fancy loading screen until the previous client disconnects.
The previous approach caused some problems with how the desktop applications and GUI frameworks are designed. Everyone can agree that desktop applications are not intended to work with concurrent physical users, even if the window instances were different for all users.

No more boilerplate code

Previously the application had to be modified to support this platform plugin. This code was needed to make the application work with the plugin:

class EventFilter : public QObject
    virtual bool eventFilter(QObject *watched, QEvent *event) override
        if (event->type() == QEvent::User + 100) {
            return true;
        } else if (event->type() == QEvent::User + 101) {
            return true;

        return false;

And install the event filter into the QGuiApplication.

No more modifications in applications are needed anymore.

How to try

So, if you want to give it a try before Qt 5.10 is released (~November 2017) do the following:


Since WebGL was modelled using OpenGLES2 as reference, first thing you will need is to have an OpenGLES2 version of Qt built. To do that, you need to pass the parameter -opengl es2 to the configure before building.

./configure -opensource -confirm-license -opengl es2

Depending on your system it is possible you will need some aditional headers and libraries to be able to use es2.

Testing the plugin

After building everything, you can try to run a Qt Quick example.

To try the photoviewer example we need to build it and run with the -platform webgl parameters:

./photoviewer -platform webgl

If you want to try the Qt Quick Controls 2 Text Editor:

./texteditor -platform webgl

Supported options

Currently, the plugin only supports an option to configure the port used by the embedded HTTP Server. If you want to listen in the default HTTP port you should write -platform webgl:port=80.

The future

The plugin will be part of Qt 5.10 release as a technology preview (TP), as it needs to be improved. Currently, the plugin contains an HTTP Server and a Web Sockets server to handle the browser connections. I’m planning to remove the servers from the plugin and start using a Lightweight QtHttpServer we are working on right now. Once it’s ready, you will be able to create an application server to launch different process inheriting the web socket to communicate with the browsers. This will allow for supporting more than one concurrent user instead of sharing applications among users.

Note: The plugin only works using the Threaded Render Loop. If you use Windows or a platform using a different render loop ensure you set QSG_RENDER_LOOP environment variable to threaded

The post Qt WebGL Streaming merged appeared first on Qt Blog.

Release 2.12.1: Visual Editor & Qt Quick Designer Improvements

V-Play 2.12.1 adds many improvements to better support Qt Quick Designer with V-Play:

  • All V-Play Core Components are now available in the side bar of the designer, which allows to use Drag’n’Drop for adding V-Play components to your QML files with the designer.
  • When V-Play components are used, the designer now supports rendering all QML items in addition to the V-Play ones.
  • Many components now include dedicated designer styles, which allows to use the designer to create UI mock-ups using V-Play, especially for V-Play Apps components.
  • Along with the new side-by-side editing which uses the Form Editor and Text Editor in a single view, this allows to speed up UI creation with V-Play even more.

Improved Visual Editor & Qt Quick Designer

V-Play is the leading cross-platform tool for mobile development in terms of rapid UI development and easy-of-use. The main reason is that V-Play takes advantage of QML, the declarative language for creating UIs with Qt – and we love it!

While everything works like a charm when coding in QML, the visual editor of Qt Creator always seemed a bit lacking and troublesome in the past. However, the Qt Quick Designer of Qt Creator made some big improvements with the recent updates.

For example, it is now even possible to use the Form Editor and Text Editor side-by-side with Qt Creator 4.3, which allows to design and code at the same time:

Qt Quick Designer V-Play 2.12.1

For more information about Qt Creator 4.3, see here.

Needless to say, this feature is amazing to speed up UI creation with QML even more, which is why we decided to improve V-Play for better support of the Qt Quick Designer. This allows all V-Play users to utilize these new IDE features and take their development to a new level.

Drag’n’Drop and Improved Component Rendering

With this V-Play update, you can fully use the Qt Quick Designer in conjunction with V-Play components.

In addition, we made all V-Play core components available for Drag’n’Drop usage from the side bar of the Qt Quick Designer. To try it out, just import the V-Play module, e.g.

import VPlayApps 1.0

All available QML types then show up in the side bar:

Qt Quick Designer V-Play 2.12.1

For this update, we’ve also added dedicated designer styles for V-Play Components. For the first time, it is now possible to drop V-Play components into the designer view and see a mock-up design of what you are building at the moment.

The preview is based on the iOS look & feel that comes with V-Play, so you don’t even need to run your app to see how it will look like!

We especially focused on better support for V-Play Apps. Here’s a short Youtube tutorial for you to get a quick overview of what’s possible:

V-Play Visual Designer – Highlights Video

In the new video below we create a new V-Play Application from scratch to show what’s possible with the designer. It covers:

  • How to create a new V-Play Application with Qt Creator.
  • A short overview of the Qt Quick Designer and how to enable side-by-side editing.
  • Using the designer to add V-Play Components via Drag’n’Drop.
  • How to layout your items using anchoring.
  • Creating a cross-platform V-Play Application with a native-styled main navigation.
  • Binding properties of a control to the property value of another item.
  • Testing the look & feel of your app on Desktop by switching between themes.

More Fixes & Improvements

Besides the highlights mentioned above, there are many other fixes and improvements for the SDK, for example V-Play Multiplayer Improvements and a new Splash Screen. For a full list of improvements and fixes to V-Play in this update, please check out our change log!

How to Update V-Play

Test out these new features by following these steps:

  • Open the V-Play SDK Maintenance Tool in your V-Play SDK directory.
  • Choose “Update components” and finish the update process to get V-Play 2.12.1 as described in the V-Play Update Guide.

V-Play Update in Maintenance Tool

If you haven’t installed V-Play yet, you can do so now with the latest installer from here. Now you can explore all of the new features included in V-Play 2.12.1!



More Posts Like This


How to Make Cross-Platform Mobile Apps with Qt – V-Play Apps

How to Make a Qt app

Release 2.11.0: All Monetization Plugins Now Free, Plugin Trial & Firebase Qt Plugin

Release 2_11

WeAreDevelopers Conference App – Open Source & Live Now!



The post Release 2.12.1: Visual Editor & Qt Quick Designer Improvements appeared first on V-Play Engine.

Qt Quick Designer – The Coffee Machine

With Qt Creator 4.3 released a month ago, coming with cool new features for Qt Quick Designer, we decided it is time to create an example that shows the complete intended workflow for Qt Quick Designer and establishes good practices.

We implemented the UI of a Coffee Machine following the reference design of a professional designer. The designer also provided all graphical assets as PNG images. In the screenshot, you can see the Resource Browser containing all the provided graphical assets. You can use these graphical assets by drag and drop.

The example is the UI of a coffee machine.

The emphasis for this example lies in a clean separation between imperative logic and the purely declarative visual design which improves the collaboration between designers and front-end developers. The separation between the declarative UI and the implementation allows us to create the visual UI using just Qt Quick Designer, while ensuring that the final result is matching the original design.

This way Qt Quick and Qt Quick Designer will maximize productivity and maintainability.

We created a video that gives an overview of the workflow and the structure of the example. Starting with a reference video from the original designer, we model the different screens using states and QML components. Each screen can be created directly in the Qt Quick Designer following the original reference design.

As seen in the video, in the property tabs you can bind properties to JavaScript expressions which allows to model behavior in a convenient way. For example we have the sliders which adjust the different coffee ingredients levels and then we bind the anchor margins of the graphical elements to JavaScript expressions.

We can define expressions controlling the active states, based on when conditions.

The animations and application logic are implemented in a single QML file. We use alias properties to define an interface between individual screens and components. Maintaining and integrating changes to the UI becomes a lot easier this way.

The source code of the example can be found in the Qt examples repository.

Contact us to learn more and discuss your needs in more detail.

The post Qt Quick Designer – The Coffee Machine appeared first on Qt Blog.

Vulkan Support in Qt 5.10 – Part 3

In the previous posts (part 1, part 2) we covered the introduction and basic Vulkan instance creation bits. It is time to show something on the screen!

QWindow or QVulkanWindow?

If everything goes well, the release of Qt 5.10 will come with at least 5 relevant examples. These are the following (with links to the doc snapshot pages), in increasing order of complexity:

The hellovulkancubes example, this time running on an NVIDIA Shield TV with Android 7.0

Checking the sources for these examples reveals one common aspect: they all use QVulkanWindow, the convenience QWindow subclass that manages the swapchain and window-specifics for you. While it will not always be suitable, QVulkanWindow can significantly decrease the time needed to get started with Vulkan rendering in Qt applications.

Now, what if one has to go the advanced way and needs full control over the swapchain and the window? That is perfectly doable as well, but getting started may be less obvious than the well-documented QVulkanWindow-based approach. Let’s take a look.

Using a Plain QWindow + QVulkanInstance

There is currently no simple example for this since things tend to get fairly complicated quite quickly. The Qt sources do provide good references, though: besides the QVulkanWindow sources, there is also a manual test that demonstrates creating a Vulkan-enabled QWindow.

Looking at these revals the main rules for Vulkan-enabled QWindow subclasses:

  • There is a new surface type: VulkanSurface. Any Vulkan-based QWindow must call setSurfaceType(VulkanSurface).
  • Such windows must be associated with a QVulkanInstance. This can be achieved with the previously introduced setVulkanInstance() function.
  • Maintaining the swapchain is left completely to the application. However, a well-behaving implementation is expected to call presentQueued() on the QVulkanInstance right after queuing a present operation (vkQueuePresentKHR).
  • Getting a VkSurfaceKHR must happen through surfaceForWindow().
  • To query if a queue family with in a physical device supports presenting to the window, supportsPresent() can be used, if desired. (like with surfaces, this is very handy since there is no need to deal with vkGetPhysicalDeviceWin32PresentationSupportKHR and friends directly).
  • It is highly likely that any Vulkan-enabled window subclass will need to handle QPlatformSurfaceEvent, QPlatformSurfaceEvent::SurfaceAboutToBeDestroyed in particular. This is because the swapchain must be released before the surface, and with QWindow the surface goes away when the underlying native window is destroyed. This can happen unexpectedly early, depending on how the application is structured, so in order to get a chance to destroy the swapchain at the right time, listening to SurfaceAboutToBeDestroyed can become essential.
  • Understanding exposeEvent() is pretty important as well. While the exact semantics are platform specific, the correct behavior in an exposeEvent() implementation is not: simply check the status via isExposed(), and, if different than before, start or stop the rendering loop. This can, but on most platforms does not have to, include releasing the graphics resources.
  • Similarly, any real graphics initialization has to be tied to the first expose event. Do not kick off such things in the constructor of the QWindow subclass: it may not have a QVulkanInstance associated at that point, and there will definitely not be an underlying native window present at that stage.
  • To implement continous updates to the rendering (which may, depending on your logic, be locked to vsync of course), one of the simplest options is to trigger requestUpdate() on each frame, and then handle QEvent::UpdateRequest in a reimplementation of event(). Note however that on most platforms this is essentially a 5 ms timer, with no actual windowing system backing. Applications are also free to implement whatever update logic they like.

Core API Function Wrappers

What about accessing the Vulkan API? The options are well documented for QVulkanInstance. For most Qt-based applications the expectation is that the core Vulkan 1.0 API will be accessed through the wrapper objects returned from functions() and deviceFunctions(). When it comes to extensions, for instance in order to set up the swapchain when managing it manually, use getInstanceProcAddr().

This is the approach all examples and tests are using as well. This is not mandatory, the option of throwing in a LIBS+=-lvulkan, or using some other wrangler library is always there. Check also the Using C++ Bindings for Vulkan section in the QVulkanInstance docs.

That’s all for now, see you in part 4!

The post Vulkan Support in Qt 5.10 – Part 3 appeared first on Qt Blog.

Qt 5.9.1 Released

I am pleased to announce that Qt 5.9.1 is released today. It contains all the latest bug fixes and improvements from Qt 5.9 branch.

Qt Creator 4.3.1 is included in the Qt 5.9.1 offline installer packages and available via the online installer.

As a patch release Qt 5.9.1 does not add any new functionality, just bug fixes and other improvements. For details of the changes compared to Qt 5.9.0 release, please check the Change files of Qt 5.9.1.

Our intention is to make more frequent patch releases for Qt 5.9 LTS than before. So if your most desired fix is not included in Qt 5.9.1 there will be more patch releases in the coming months.

If you are using the online installer, Qt 5.9.1 and Qt Creator 4.3.1 can be updated using the maintenance tool. Offline packages are available for commercial users in the Qt Account portal and at the qt.io Download page for open-source users.

For users targeting iOS we have identified an issue which can be fixed with an additional iOS patch. We know this is unfortunate, but the alternative was to delay the entire release for over one month. In light of this we thought it would be better to release 5.9.1 today, with a hot patch for iOS.

The post Qt 5.9.1 Released appeared first on Qt Blog.

Qt Creator 4.3.1 released

We are happy to announce the release of Qt Creator 4.3.1. This release contains a range of bug fixes.

Most importantly we fixed a memory leak in code completion, which lead to out-of-memory crashes after a while, especially for users on 32-bit Windows. The new version also includes a multitude of improvements for the CMake integration, fixes running applications on iOS 10.3 devices, and mends some regressions related to the project tree.

For a more detailed overview of the included improvements, take a look at our change log.

Get Qt Creator 4.3.1

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.3.1 is also available through an update in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.3.1 released appeared first on Qt Blog.

Release 2.12.0: Qt 5.9 & Qt Creator 4.3 Support

V-Play 2.12.0 adds support for Qt 5.9 and the latest Qt Creator 4.3. Qt 5.9 adds many great features like support for gamepads and 3D key frame animations. Qt Creator 4.3 adds a much improved design mode, which allows you to write QML code side-by-side with a visual representation of the code. This allows rapid prototyping of UIs.

V-Play 2.12.0 Improvements

V-Play is now compatible with Qt 5.9 and Qt Creator 4.3, which adds an improved QML Designer. The biggest benefit of the new QML Designer is the new live preview of your QML code. You can have your UI side-by-side with QML code, which allows to further accelerate the development process.

Qt Quick Designer Side by Side Visual and Code

Some of the V-Play components now also support the QML Designer and visual development. The supported components include GameWindow, App, Scene, Page, NavigationStack and also most of the other components are working. With this improvement, you can now adjust component properties with a nice visual editor.

Other improvements of this V-Play release:

  • You can use an improved icon-font handling within games and apps and use the latest FontAwesome version 4.7.0 with the IconType component.
  • The Friends View now has an improved UI. You can use the V-Play friends system within V-Play Multiplayer to allow users to send friend requests and then show the friends in a separate section of the leaderboard. You can also use this friend system to allow sending messages only between accepted friends to prevent spam in your in-app messages. This improvement is live in the released card game One Card! for iOS and Android.
    onecard-menu onecard-game
    Download One Card on iOS Download One Card on Android
  • With the AppButton::textFont property, you can now access and modify all font properties of the text within AppButton.
  • The Component Showcase Demo App configuration for ios/Project-Info.plist now includes the NSContactsUsageDescription entry, which is required for NativeUtils::storeContacts() since iOS 10.
  • Use the new Dialog::autoSize property to decide whether the dialog uses a fixed height or a dynamic height based on the Items you add as dialog content.
  • Incorrect warning for publish builds about using DEPLOYMENTFOLDERS is no longer displayed when QRC is actually used instead. This is relevant when protecting your source code for published apps.

Qt 5.9 Improvements for Mobile App Development

Qt 5.9 added many improvements and was shipped on time. This indicates that the new CI system The Qt Company is now be using yields great results. These are our favorite Qt 5.9 improvements, with a focus for mobile app or game development:

Qt 3D: Animations, Physics Based Rendering (PBR), Level of Detail

Qt 3D got a lot better with the Qt 5.9 release. These are our highlights:

  • You can now use key frame animations! This is an important feature, as it allows you to animate your 3d objects in a dedicated animation tool like Blender or Autodesk Maya, and then import this animation with Qt 3D.
  • A Physics Based Rendering (PBR) material is now available in Qt3DExtras.
  • A new Level of Detail component allows loading different 3D models based on projected screen size or distance. This enables you to have better performance.
  • You can now render Qt Quick 2 scenes to a texture and interact with them in a 3D world.
  • 3D text is available in Qt3DExtras:

Improved QML Performance

Thanks to support for ahead-of-time generation of QML type caches and support for shader program binaries now being cached, the initial application startup time, QML loading time and also view initialization times got improved. Also, the rewritten JavaScript garbage collector yields better performance.

Qt Location and Positioning

  • You can now tilt and rotate maps, both through the APIs and through touch gestures.
  • If you want to overlay items to maps this is now easier too.
  • On iOS, you can now collect positioning data even when the application is in the background.
  • There’s also a new plugin that adds support for Mapbox and both raster and vector tiles, using their OpenGL based map rendering engine:

Mapbox OpenGL Plugin

GamePad Support and More

Qt now supports GamePads which is great for improving controls for games on PC, Android, iOS or tvOS devices. The GamePad support works nicely together with the V-Play TwoAxisController component, which is used in several of the sample games available like our Super Mario like platformer game.

Other improvements like Qt NFC support when running as an Android service or better Qt Charts makes this the best Qt release yet. For a list of all new features in Qt 5.9, see here.

Qt Creator 4.3 Support

The absolute highlight of Qt Creator 4.3 is the new live preview of your QML code in the Qt Quick Designer (alias QML Designer):

Qt Quick Designer - Mixed Design and Edit Mode


It allows editing the QML code side by side with the form editor as a preview. In addition to this preview, you can also use the property editor together with the text editor. Qt Quick Designer will always select the item that currently contains the cursor.

So if you just forgot the name of a property or enum, you can now use the property editor instead. With the improved designer, you can now create UIs seamlessly by mixing QML code and visual editing. This really combines the best of two worlds, because you can now stay in the design mode instead of switching between code and design modes.

Internally, we were using the Code editing mode most of the time. We have now changed our workflow and development process to use the designer more and have already experienced a faster development process. We’d highly recommend you to try out the new design mode, it will save you a lot of hours and makes development with QML even better. :)

See here for a detailed list of new Qt Creator 4.3 featuers, and here for a list of Qt Quick Designer improvements.

How to Update V-Play

Test out these new features by following these steps:

  • Open the V-Play SDK Maintenance Tool in your V-Play SDK directory.
  • Choose “Update components” and finish the update process to get V-Play 2.12.0 as described in the V-Play Update Guide.

V-Play Update in Maintenance Tool

  • After updating, remove Qt 5.8 from your installed components: Click on “Add or remove Components” and unselect Qt 5.8. Because V-Play is not compatible with Qt 5.8 anymore, it is best to remove these kits.
  • When you now start Qt Creator, it automatically detects the kits for Qt 5.9, which you can use to build your V-Play projects.
  • To enable one of the new Qt 5.9 kits, click “Projects” on the left side of Qt Creator and enable your desired kit in the section “Build and Run”.

If you haven’t installed V-Play yet, you can do so now with the latest installer from here. Now you can explore all of the new features included in V-Play 2.12.0!


For a complete list of the changes to V-Play with this update, please check out our change log!

More Posts Like This


How to Make Cross-Platform Mobile Apps with Qt – V-Play Apps

How to Make a Qt app

Release 2.11.0: All Monetization Plugins Now Free, Plugin Trial & Firebase Qt Plugin

Release 2_11

WeAreDevelopers Conference App – Open Source & Live Now!



The post Release 2.12.0: Qt 5.9 & Qt Creator 4.3 Support appeared first on V-Play Engine.

Using Compiler Explorer with Qt

One of my preferred developer tools is a web called Compiler Explorer. The tool itself is excellent and useful when trying to optimize your code.
The author of the tool describes it in the Github repository as:

Compiler Explorer is an interactive compiler. The left-hand pane shows editable C/C++/Rust/Go/D/Haskell code. The right, the assembly output of having compiled the code with a given compiler and settings. Multiple compilers are supported, and the UI layout is configurable (the Golden Layout library is used for this). There is also an ispc compiler for a C variant with extensions for SPMD.

The main problem I found with the tool is, it does not allow to write Qt code. I need to remove all the Qt includes, modify and remove a lot of code…

So I decided to modify the tool to be able to find the Qt headers. To do that first of all, we need to clone the source code:

git clone git@github.com:mattgodbolt/compiler-explorer.git

The application is written using node.js, so make sure you have it installed before starting.

The next step is to modify the options line in etc/config/c++.defaults.properties:

-fPIC -std=c++14 -isystem /opt/qtbase_dev/include -isystem /opt/qtbase_dev/include/QtCore

you need to change /opt/qtbase_dev with your own Qt build path.

Then simply call make in the root folder, and the application starts running on port 10240 (by default).

And the mandatory screenshoots 🙂



The post Using Compiler Explorer with Qt appeared first on Qt Blog.

Digital Instrument Cluster with Qt Quick Designer and Qt Safe Renderer

The growth of reconfigurable digital instrument clusters in the automotive industry is exploding. This is driving a need for high performance graphics technologies, designer tooling and solutions for safety critical systems.

The highly optimized Qt Quick technology is a great fit for creating modern digital clusters. Its plug-able back-end technology supports various rendering methods from OpenGL down through OpenVG to software rendering. This flexibility means you can target a wide range of price/performance points such as the NXP i.MX6 family which ranges from quad core with GPU to single core and no GPU.

For the designer, the Qt Quick Designer allows you to design and prototype the cluster user experience without writing any code. If you do chose to edit the QML code the your changes are immediately reflected in the live preview feature of Qt Quick Designer.

Safety critical operation is a key requirement in digital clusters. To satisfy safety requirements the safety critical functionality is separated from the other parts. What the automotive industry calls tell-tales is the safety critical part, these are the warning lamps for things such as airbag, oil level, engine temperature and brakes. These need to be rendered in a separate software partition that has been certified as designed and implemented per the industry’s relevant standards. The Qt Safe Renderer is our implementation that meets these standards.

But UI designers don’t really want to be bothered by such details. They just want to design the UI as a whole, marking items as safety critical is about the extent of what they need to know. We have added this capability into the Qt Quick language and Qt Quick Designer and to make things even more convenient this is done automatically when using one of Qt’s comprehensive set of ISO 7000 standard icons for warning and other indicators. Qt’s drag-and-drop visual design tooling really simplifies this design flow for adding these icons.

Once the design is complete the build process separates the safety critical UI elements from the main UI.  We use the Qt safe Renderer component to render the safety critical items and also to monitor the operation of the main UI. It is critical that any error in operation of the main UI does not impact the correct rendering of the safety critical items. The Qt Safe Renderer will restart the main UI as appropriate should it detect an error. For more details on the Qt Safe Renderer check out this blog post.

To show how all this comes together we created a video. It shows how to design a digital instrument cluster, deploy it to a device and how the Qt Safe Renderer works in practice.

As you can see, Qt offers tools that make design and prototyping digital instrument clusters intuitive for people who prefer visual design tools over coding. As always with Qt, the full power of QML, the Qt framework and C++ are accessible to create even more complex system logic.

You can get going quickly by looking at the code for the digital instrument cluster example used in the video in the Qt examples repository. Some of the Qt Quick components of the example have backends written in C++ which means they need to be built in order to be available in Qt Quick Designer. To do this, build the project for your desktop platform and in Qt Creator go to Tools > Options > Qt Quick > Qt Quick Designer and enable Use QML emulation layer which is built by the selected. For more details on how to integrate custom QML modules have a look at the Qt documentation here.

Contact us to learn more and discuss your needs in more detail.

The post Digital Instrument Cluster with Qt Quick Designer and Qt Safe Renderer appeared first on Qt Blog.

A tale of 2 curves

As my first subject for this animation blog series, we will be taking a look at Animation curves.

Curves, or better, easing curves, is one of the first concepts we are exposed to when dealing with the subject of animation in the QML space.

What are they?

Well, in simplistic terms, they are a description of an X position over a Time axis that starts in (0 , 0) and ends in (1 , 1). These curves are …

The post A tale of 2 curves appeared first on KDAB.

Vulkan Support in Qt 5.10 – Part 2

In the previous instalment we looked at the background for Qt 5.10’s upcoming Vulkan support. Let’s now start digging out into the details.

Obtaining a Vulkan-Enabled Qt Build

When building Qt from sources on Windows, Linux or Android, Vulkan support is enabled automatically whenever a Vulkan header is detected in the build environment. Windows is handled specially in the sense that the environment variable VULKAN_SDK – set by the LunarG Vulkan SDK – is picked up automatically.

Check the output of configure (also available afterwards in config.summary):

Qt Gui:
  Vulkan ................................. yes

If it says no, go to qtbase/config.tests/qpa/vulkan, run make, and see why it did not compile.

As mentioned in part 1, neither the QtGui library nor the platform plugins link directly to libvulkan or similar. Same applies to Qt applications by default. This comes very handy here: a Vulkan-enabled Qt build is perfectly fine for deployment also to systems without any Vulkan libraries. No headache with missing DLLs and such. Naturally, once it turns out Vulkan is not available at runtime, QVulkanInstance::create() will fail and will return false always. It must also be noted that the applications themselves can choose to link to a Vulkan (loader) library, if they have a reason to do so: all it takes is adding LIBS+=-lvulkan or similar to the .pro file.

Getting a Vulkan Instance

In Vulkan all per-application state is stored in a VkInstance object, see the the specification for a detailed overview. In Qt, Vulkan instances are represented by QVulkanInstance. This is backed by a QPlatformVulkanInstance following the usual QPA patterns. The platform plugins, at least the ones that are interested in providing Vulkan support, are expected to provide an implementation for it under the hood. As described earlier, this currently covers windows, xcb and android.

Following the familiar pattern from QWindow and the QOpenGL* classes, QVulkanInstance performs no initialization until create() is called. The loading of the Vulkan library (or the loader library which in turn routes to a vendor implementation) happens only at this point. (with a few exceptions, see below)

The resulting VkInstance can be retrieved via vkInstance().

Quite unsurprisingly, QVulkanInstance allows specifying the usual instance configuration options, like the desired API version, and, most importantly, the list of layers and extensions to enable.

While the Qt APIs allow including unsupported layers and extensions too – since it filters them out automatically – it may still be necessary in some cases to examine the names and versions of all supported layers and extensions. This can be done at any time – even before calling create() – via supportedExtensions() and supportedLayers(). These will naturally trigger an early loading of the Vulkan implementation when needed.

It is worth knowing that the surface-related extensions that are required for basic operation, such as VK_KHR_surface or VK_KHR_win32_surface, are automatically added to the list by Qt, and applications do not have to worry about these.

Typical main() Patterns

In the end the main() function for a Qt application with a Vulkan-capable window (or a Vulkan-capable window embedded into a QWidget hierarchy) will typically look like the following:

int main(int argc, char **argv)
    QGuiApplication app(argc, argv); // or QApplication when widgets are involved

    const bool enableLogsAndValidation = ...

    QVulkanInstance inst;

    if (enableLogsAndValidation) {

#ifndef Q_OS_ANDROID
        inst.setLayers(QByteArrayList() << "VK_LAYER_LUNARG_standard_validation");
#else // see Android-specifics at https://developer.android.com/ndk/guides/graphics/validation-layer.html
                       << "VK_LAYER_GOOGLE_threading"
                       << "VK_LAYER_LUNARG_parameter_validation"
                       << "VK_LAYER_LUNARG_object_tracker"
                       << "VK_LAYER_LUNARG_core_validation"
                       << "VK_LAYER_LUNARG_image"
                       << "VK_LAYER_LUNARG_swapchain"
                       << "VK_LAYER_GOOGLE_unique_objects");

    if (!inst.create())
        qFatal("Failed to create Vulkan instance: %d", inst.errorCode());

    MyVulkanWindow w;
    w.resize(1024, 768);

    return app.exec();

In most cases there will be a single QVulkanInstance. This can live on the stack, but has to be ready before creating the QWindow or QVulkanWindow-derived window objects since they will need to be associated with a QVulkanInstance. (more on this and other window-related topics in part 3)

The logging category qt.vulkan can be very helpful for troubleshooting. When enabled, both QVulkanInstance and, if used, QVulkanWindow will print a number of interesting things on the debug output, during initialization in particular. The hard-coded setFilerRules() call in the code snippet above is not necessarily the best approach always, but works well for platforms where environment variables (QT_LOGGING_RULES) are problematic. On Windows and Linux it is better to control this via the environment or configuration files.

When it comes to output from Vulkan and, first and foremost, the validation layers, QVulkanInstance offers the convenience of automatically redirecting these messages to qDebug. By default VK_EXT_debug_report gets enabled and redirection is active. If this is not desired, set the corresponding flag before calling create().

Working with External Graphics Engines

During the lifetime of the Qt 5.x series, there has been a growing focus on making Qt Quick and the underlying OpenGL enablers more interoperable with foreign engines. This led to productizing QQuickRenderControl, the enhancements to QOpenGLContext for adopting existing native contexts, and similar improvements all over the stack.

In the same spirit QVulkanInstance allows adopting an existing VkInstance. All this takes is calling setVkInstance() before create(). This way every aspect of the VkInstance creation is up to the application or some other framework, and QVulkanInstance will merely wrap the provided VkInstance object instead of constructing a new one from scratch.

That’s all for now, stay tuned for part 3!

The post Vulkan Support in Qt 5.10 – Part 2 appeared first on Qt Blog.

CMlyst 0.3.0 released

CMlyst is a Web Content Management System built using Cutelyst, it was initially inspired by Wordpress and then Ghost. So it's a mixture of both.

Two years ago I did it's first release, and since them I've been slowly improving it, it's been on production for that long providing www.cutelyst.org web site/blog. The 0.2.0 release was a silent one which marks the transition from QSettings storage to sqlite.

Storing content on QSettings is at first quite interesting since it's easy to use but it showed not suitable very fast, first it kept leaving .lock files, then it's not very fast to access so I had used a cache with all data, and a notifier updated that when something changed on the directory, but this also didn't properly triggered QFileSystemWatcher so once a new page was out the cache wasn't properly updated.

Once it was ported to sqlite, I decided to study how Ghost worked, this was mainly due many Qt/KDE developer switching to it. Ghost is quite simplistic, so it was very easy to try to provide something quite compatible with it, porting a Ghost theme to CMlyst requires very little changes due it's syntax being close to Grantlee/Django.

Due porting to sqlite it also became clear that an export/import tool was needed, so you can now import/export it in JSON format, pretty close to Ghost, actually you can even import all you Ghost pages with it, but the opposite won't work, and that's because we store pages as HTML not Markdown, my feeling about markdown is that it is simple to use, convenient to geeks but it's yet another thing to teach users which can simply use a WYSIWYG editor.

Security wise you need to be sure that both Markdown and HTML are safe, and CMlyst doesn't do this, so if you put it on production be sure that only users that know what they are doing use it, you can even break the layout with a not closed tag.

But don't worry, I'm working on a fix for this, html-qt is a WHATWG HTML5 specification parser, mostly complete, but the part to have a DOM, is not done yet, with it, I can make sure the HTML won't break layout and remove unsafe tags.

Feature wise, CMlyst has 80% of Ghost features, if you like it please help add missing features to Admin page.

Some cool numbers

Comparing CMlyst to Ghost can be trick, but it's interesting to see the numbers.

Memory usage:

  • CMlyst uses ~5MB
  • Ghost uses ~120MB

Requests per second (using the same page content)

  • CMlyst 3500/rps (production mode), 1108/rps (developer mode)
  • Ghost 100/rps (production mode)

While the RPS number is very different, on production you can use NGINX cache which would make the slow Ghost RPS not a problem, but that comes to a price of more storage and RAM usage, if you run on an AWS micro instance with 1GB of RAM this means you can have a lot less instances running at the same time, some simple math shows you could have 200 CMlyst instaces vs 8 of Ghost.

Try it!


Sadly it's also liked soon I'll be forking Grantlee, the lack of maintenance just hit me yesterday (when I was going to release this), Qt 5.7+ has changed QDateTime::toString() to include TZ data which broke Grantlee date filter which isn't expecting that, so I had to do a weird workaround marking date as local to avoid the extra information.

Mobile App Development with Qt Part 1 – Top Considerations for Choosing Your App Development Framework

by Christian Feldbacher, V-Play [Qt Technology Partner] (Qt Blog)

Choosing a framework for your next cross-platform app is an important decision. In this post we’ll cover multiple factors to consider when choosing your app development framework and how that should support your business strategy.

What to Consider

Determine the reasons why you may need a cross-platform mobile app:

  • Do you want to improve your brand and better position your company in mobile app stores?
  • Do you want to make your employees more productive with internal apps that they can use on their tablets or phones?
  • Do you want to save the cost of having a dedicated Android and iOS development team and instead have one team that’s able to cover all platforms with a single source code basis?
  • Will you have to maintain your app on multiple platforms over a long period of time? Your iOS and Android versions may drift apart in terms of functionality and features because maintaining multiple platforms requires a lot of effort and dedicated experts for iOS and Android. With a cross-platform solution, you can avoid different timelines per platform and reduce maintenance costs.
  • Do you need to reduce the amount of duplicate code for multiple platforms such as iOS, Android and Desktop?
  • Do you have existing business logic or even a desktop application written in C++ and now want to bring it to mobile?

If you answer yes to just a couple of these questions, you should be considering a cross-platform mobile app strategy.

Let’s dive into the question, what your cross-platform framework should provide:

Animated UIs

Successful apps all have one thing in common: a great user experience and smooth animations that give the user a sense of joy.

So to create a modern mobile app, the user interface and the screen transitions need to be animated. Adding animations and prototyping different UIs should be the core strength of your framework. Take Qt Quick (aka QML) as an example – QML was essentially designed and written with this goal in mind.

If you’ve developed native apps for Android or iOS before, you’ll know that getting these animations right is a major time sink. Using a declarative design approach will save you time and money.  QML allows you to easily animate any user interface element with dozens of different easing types and gives your app that extra level of polish

(Very) Few Lines of Code

Another benefit of QML is its declarative structure: You can define UIs and animations in less than 20 lines of code and they’ll still be easy to understand and read. With advanced features, such as property bindings, you can save even more lines of code. This requires a lot of boilerplate code in other programming languages.

Native Performance

The basis of QML is C++ which has much better performance than any JavaScript-based framework. In addition, the rendering of QML is handled from a modern scene graph optimized for mobile. Thanks to this scene graph and C++ basis, the animations and loading times are on a native level, just like a regular iOS or Android app.

Business App Requirements

Qt supports many requirements in modern business apps. It allows you to access your backend APIs via WebSockets or REST/HTTP, add location and maps services, display HTML 5 content, access sensors, multimedia, databases, localization features, and more connectivity access via Bluetooth LE or NFC.

Compatibility with Your Existing Business Logic

If you have existing business logic in C++, you can include that code and reuse it for your mobile apps. You don’t need to start from scratch and can focus on providing a great UI to users.


If a native feature you need is not covered by Qt yet, you can add it on your own and then provide it to QML with a clean scripting API, from native Java or Objective-C/Swift code to QML. This also allows you to add 3rd party SDKs, which might only be available for iOS or Android. Some of the most popular mobile services are available in a cross-platform format as V-Play Plugins – see the upcoming part 2 for more details.

Components Designed Specifically for Mobile App Development

Qt with QML fulfils many mobile app requirements, but you can make it even better by taking advantage of components that are specifically designed for mobile app development, such as those available in the V-Play Apps SDK , which provides components on top of Qt to simplify and accelerate mobile app development with Qt.



V-Play Apps components were designed with mobile-first in mind. This means you get components used by the most successful and popular mobile apps on iOS and Android as cross-platform components.

This is the first part of the “Mobile App Development with Qt” series. In the second part, you will learn about the differences between platforms and how you can support these differences with a shared code base using Qt and V-Play Apps.

As soon the second part is released, the link will be added here.

The post Mobile App Development with Qt Part 1 – Top Considerations for Choosing Your App Development Framework appeared first on Qt Blog.

GammaRay 2.8.0 Release

We have released version 2.8.0 of our Qt application introspection tool GammaRay. GammaRay allows you to observe behavior and data structures of Qt code inside your program live at runtime.

A big focus in this release is improvements to the Qt Quick inspector, which gained layout helper grids and Qt Quick Controls 2 tracing, as well as initial support for the software renderer. We have also optimized the performance of the remote view, which previously managed to saturate a …

The post GammaRay 2.8.0 Release appeared first on KDAB.

Monkeystudio homepage is moving


After some months (years :p) without any special move in MkS I decided to *archive* the website.
Currently it cost me a lot of time to maintain the web part of the MkS project, update drupal, update any of its modules etc.
This is inefficient because to be honest, nothing in this CMS is serving us apart the blog/story/wiki.
So I decided to move to a plain html/js static website which posts, blogs and wiki pages are just requested from xml request from a json file.
i will just have to update this json file to add any new content, very easy to handle / maintain.

read more

Built with Qt: Episode II – Driving the Automotive Industry

Qt is putting the pedal to metal within the automotive industry with our Qt Automotive Suite offering and we have a lot of interesting automotive related #BuiltwithQt cases, videos and demos. We are attending TU Automotive in Detroit this week, where both our partners and The Qt Company will have booths displaying the latest and greatest within automotive.

We had so many automotive showcases at Embedded World 2017, from both our partners and The Qt Company, and in this blog you will find some of the selected ones. It is really cool to see how this industry is driving technology forwards with innovation. There is a good chance you’ll see some of these demos at the TU Automotive event as well.

Multi-screen demo on single SoC with Integrity RTOS

As the pressure on proving a unified UX across all screens within automotive is rising, there is also a pressure to keep costs down. QML can save you up to 40% off the hardware cost and really allows you to squeeze the juice out of your hardware. In the following video you can see our multi-screen demo, running on a single SoC using Integrity RTOS and the application manager in the Qt Automotive Suite, based on the Wayland Compositor, for managing the complex architecture.

Gesture Controlled Infotainment

Like straight out of Minority Reports, gesture control is on the horizon – who likes talking to your car anyways when you can make hand gestures to control the temperature of your car? The future is interesting. Check out the gesture controlled IVI using Qt Automotive Suite with our partner, brightONE:

All-in-One Carputer

Our partner, LinkMotion has developed something they call a Carputer, it’s a nifty name for an all-in-one solution consisting of hardware and the Qt Automotive Suite supporting. Oh, and the Carputer is used by a car manufacturer that creates super-fast cars. Some might know them as the raging bull of the automotive industry. Check out LinkMotion’s demo of their Carputer:

Worlds Fastest Electric SuperCar

Not only is the raging bull of automotive using Qt, but our friends over at Rimac Automobili have created the world’s fastest electric supercar with a Qt based IVI and digital instrument cluster. The world’s fastest electric supercar deserves the world’s fastest software and there is no wonder why they choose Qt. I could also name some other fast electric mass produced cars who have their in-vehicle screens built with Qt (they might be from Californi-a), but I’ll save that for later. As Damir from Rimac so nicely states: “The Rimac Concept_One is limited to 355 km/h or 220 mph” ­– I wonder how fast it can go without the limitation. And how fast will cars go when they are all autonomous? The roads will be far safer. Will there even be speed limits?

TU Automotive

We are going to be at TU Automotive in Detroit this week. Do come and see us and talk with us about what we can do for your automotive program. Here are some of the featured partner demos at TU Automotive which are built with Qt!

  • Harman | HCAT HMI Solution & Echo Cancelations and Noise Reduction software 
  • Green Hills | Automotive Instrument Cluster HMI built with Qt on INTEGRITY 
  • QNX | QNX Hypervisor, instrument cluster and infotainment built with Qt and featuring Qt, HTML and GL 
  • Mapbox | Qt Automotive Suite running on Intel NUC featuring Mapbox Vector Map integration

At the Qt booth we will be showing:

Multiple Display Synchronization with a Single Processor

Streamline reference UI/UX designs for IVI systems including multiple IVI applications and application store development

  • Independent App process per app enables modern updating functionality
  • Display on multiple screens
  • Qt Wayland Compositor for display composition
  • Embedded Linux running on Intel NUC
  • Qt Automotive Suite

Qt Fast Boot Instrument Cluster  

Boot up your project in 1.2 seconds with Qt (Qt applications are not the limiting factor – the OS and hardware is)

  • Toradex Apalis NXP i.MX6 Quad core processor, 1GHz
  • 1GB DDR3 RAM, 4GB eMMC
  • 1280 x 480 Display
  • Embedded Linux Qt for Device Creation

Check out the Toradex Apalis i.MX6 going head to head with the NXP Sabre i.MX6 to achieve the fastest boot time on a digital instrument cluster:

Qt 3D Studio for Future Automotive Instrument Cluster UX/UI

Qt 3D Studio is an authoring tool for rapidly creating interactive 3D interfaces and applications and was the biggest contribution to Qt ever. Thank you, NVIDIA!

  • WYSIWYG editor for 3D scenes and animations
  • Application deployed on Intel NUC and Google Pixel C
  • Built material and effects library
  • Mix 2D and 3D user interfaces by integrating Qt Quick
  • Combining Qt 3D Studio, Qt Quick Designer, and State Chart Editor

Check out how a 3D HMI is built in less than 30 minutes in the following video:

Qt Automotive Suite gets you first to the finish line whether is in your software development project or in one of the super-fast cars running Qt. If you have questions about creating the digital automotive cockpit of the future, whether it be a cluster with safe rendered components extended with a heads-up display, smack bang in the middle of your windscreen, showing you the way to go in an augmented reality futuristic way or an IVI with a branded look and feel across all screens. And with Qt you can also re-use your code so if you want to put your cockpit in your pocket with our mobile offering and create your companion app for iOS or Android – we’ve got you covered. Qt really does have everything you need for your automotive program. We even create branded SDKs to make sure your teams and third parties are all aligned using the same tools and libraries. Contact us or come talk to us at TU Automotive. Be there or be…well…outdated.

The post Built with Qt: Episode II – Driving the Automotive Industry appeared first on Qt Blog.

Creating PDF/A documents with Qt

As there were some complex issues around conformity in PDF document creation within Qt, KDAB let me spend some time digging into it so we could make sure that Qt’s PDF engine generates documents up to ISO-standard.

Nowadays, many official institutions have the requirement to archive their data digitally and PDF is a first class citizen for this purpose. However, since the overall PDF standard is too complex, to guarantee that PDF documents can be rendered in their entirety in

The post Creating PDF/A documents with Qt appeared first on KDAB.

Renewed Qt Support Services

The Qt Company support team works hand-in-hand with Qt R&D developers and we are 100% committed to ensuring that you succeed with your project.

We have recently launched new support services and in this blog post I would like to introduce you to the new offering and in addition give you an introduction to the Qt Support team. The new support offering has been modified and we have launched two different levels of support, which have been named ‘Standard’ and ‘Premium’ Support. In addition to our standard offering, all 5.x releases can be extended with Extended Support.

The Team

We have a team of experienced software engineers working in Qt Support. All of us have a long background in software development and with Qt. Currently we are working from three different locations, Oulu, Oslo and Santa Clara and we are considering expanding our locations to Tokyo, Berlin and Boston during this year.
With new locations covering multiple time zones, we will be able to give even quicker responses to our Asian and US based customers.
The Qt Support team is part of Qt R&D and we work closely with the development teams. Being closely connected with where the development happens means that we are always up to date with the latest new features and we know the best practices on how to leverage these new features. For you as a Qt user, it also means that if you have an issue, we know who to contact and we can solve your challenges quickly.

Standard and Premium Support

Earlier we had three different support levels, but now we have reduced those to two and changed the names of two levels moving forwards. The previously known Silver Support will now be called ‘Standard Support’. The SLA terms are still the same as earlier with Silver Support. The new Support plan name, Standard Support, will be visible to you in your Qt Account.
Gold support has been renamed to Premium Support. Current Gold support customers will continue to get their service under the old Gold Support SLA.
The entry level support, Bronze Support has been phased out.

All Qt customers with an active license (except for start-up licensees) are entitled to Qt Support. Standard Support is bundled with all new Qt licenses. It comes with a two business day response time guaranteed and provides you priority to the customer reported Qt errors.
If a more personal and quicker support service is required, the Premium Support is the way to go. With Premium Support, we offer a dedicated support person and the possibility to utilize online chat through remote desktop connection. With Premium Support, our target is to respond within the same workday as the issue is reported. Also, reported bugs and other issues are treated with even higher priority than with Standard Support. With Premium Support, we also analyze the complete customer application code base and debug that instead of requiring a minimal test application where the issue is reproduced.

Support Level Details
Standard Support Premium Support
Support on Qt APIs, functions, methods and programming techniques Yes Yes
Guaranteed response time Within 48 business hours Within 24 business hours
Bug fix prioritization* Priority High Priority
Support on using Qt for your specific project Yes
Dedicated Qt Support contact Yes
Instant messaging with dedicated support contact Yes

*Within reasonable efforts, not every bug is fixable as part of Qt Support

Extended Support

Qt 5.4 and later releases are currently supported by default. If support is required for older and unsupported Qt 5.x releases the support can be separately purchased as Extended Support. This will allow the customer to ask questions and report issues occurring on these older Qt versions – in the same way as if the phased out Qt version was still officially supported.
By default, releases from Qt 5.6 and onward are supported for one year and LTS releases are supported for three years starting from the 5.x.0 release.

Support periods for Qt 5.x releases
Qt Version Standard Support Until Extended Support Available
5.0.x – 5.3.x Support already ended. Yes
5.4.x 01.07.2017 Yes
5.5.x 16.03.2018 Yes
5.6.x (LTS) 16.03.2019 Yes
5.7.x 16.06.2017 Yes
5.8.x 23.01.2018 Yes
5.9.x (LTS) 31.05.2020 Yes

More information regarding the different support levels can be found on the Qt Support pages.
Both Extended Support and Premium Support upgrades are targeted for complete development teams.

The Help We Provide

In most cases, Support provides a fix or a workaround for the reported issue. The remaining issues are then followed up by our development teams. Qt Support flags these bugs as being originating from commercial customer and thus gets higher priority when R&D prioritizes bugs to be fixed. Therefore, it is important that all the bugs that the commercial Qt customers encounter are also reported to the Qt Support team.

Even though helping customers tackle Qt bugs is a prominent function of the support team, we also do a lot more. Most questions sent to Support are actually not related to bugs, but rather related to finding optimal coding solutions for the problems customers are facing in their code. We have also been compiling a Qt Support FAQ page, which deals with the most common issues. The Qt Support FAQ is accessible through your Qt Account.

We have been measuring Qt support customer satisfaction for many years now and we have always had a high rating. 9/10 customers have been satisfied or very satisfied with our service. Our main target is to keep our customers happy and productive with Qt. The future of our framework relies on successful projects and therefore we put a lot of effort into providing the best support possible.

You can find more information about Qt Support on the support pages or via Qt Account and we are also more than happy to provide you with a quote. Please do contact us if you have any questions regarding our offering.

The post Renewed Qt Support Services appeared first on Qt Blog.

Vulkan Support in Qt 5.10 – Part 1

As some of you may have heard, one of the new features in Qt 5.10 is the introduction of a set of basic Vulkan enablers. Now that Qt 5.9 is out, it is time to take a look at what this covers (and does not cover) in practice. In order to keep things fun and easy to read, this is going to be split into a series of shorter posts. It must also be mentioned that while the new features mentioned here are all merged to the dev branch of qtbase, there is no guarantee they will not change until the release of Qt 5.10.


Qt 5.8 started the research and implementation for gradual improvements when it comes to supporting graphics APIs other than OpenGL. There the focus was mainly on Qt Quick, and scenegraph backends that either do not involve new platform specifics (software) or are available on a single platform/windowing system only (Direct3D 12).

As shown in the pre-work for our D3D12 experiment, getting started with such APIs is easy: 1. grab the native window handle (for example, in case of Windows, QWindow::winId() is the HWND); 2. add your platform-specific code to render stuff; 3. done!

Now, the same is of course possible with Vulkan, as proven by the various projects on GitHub and elsewhere. So what is the point in touching QtGui, the QPA interfaces, and the platform plugins?

Well, things become more interesting when multiple platforms come into play: the way windowing system integration is done in Vulkan requires writing platform-specific code, likely leading to a bunch of ifdefs or similar in cross-platform applications.

Given that we have a cross-platform framework (Qt), it is fairly natural to expect that it should help with abstracting and hiding these bits.

So instead of this:

QWindow *window;

#if defined(VK_USE_PLATFORM_WIN32_KHR)
    VkWin32SurfaceCreateInfoKHR createInfo;
    createInfo.hwnd = (HWND) window->winId();
    err = vkCreateWin32SurfaceKHR(...);
    VkWaylandSurfaceCreateInfoKHR createInfo;
    err = vkCreateWaylandSurfaceKHR(...);
    VkAndroidSurfaceCreateInfoKHR createInfo;
    err = vkCreateAndroidSurfaceKHR(...)
#elif defined(VK_USE_PLATFORM_XCB_KHR)
    VkXcbSurfaceCreateInfoKHR createInfo;
    err = vkCreateXcbSurfaceKHR(...)
#elif ...

why not have something like the following:

QWindow *window;

VkSurfaceKHR surface = QVulkanInstance::surfaceForWindow(window);

The windowing system specifics are now conveniently handled in Qt’s platform plugins. No more ifdefs.

The second important motivation factor is that even the D3D12 experiment has shown that many applications are happier with a higher level convenience window class, like QD3D12Window, following the example of QOpenGLWindow. These are inherently limited in some ways, but avoid the need for doing everything from scratch with QWindow (and juggling with surfaces like in the above example…).

Using QWindow directly remains the most powerful way always, giving full control to the application, but as we will see later, doing a fully featured and stable Vulkan-based QWindow is not exactly trivial (think swapchains, exposeEvent(), resizing, QPlatformSurfaceEvent, etc.). Hence the introduction of QVulkanWindow.

What This Is Not

Before moving on to the new QVulkan* classes in detail, let’s clarify quickly what the Vulkan support in Qt 5.10 really is:

  • Qt 5.10 enables applications to perform cross-platform Vulkan rendering in a QWindow and the convenience subclass QVulkanWindow.
  • Besides abstracting the windowing system specifics, a thin wrapper is provided for Vulkan instances and the instance and device specific functions of the core Vulkan 1.0 API.
  • The Vulkan API is not abstracted or hidden in any way. Qt does what it should, i.e. helping with windowing, platform specifics, and function resolving for the core API, but no more than that.
  • Vulkan-based QWindows can be combined with QWidget-based UIs using QWidget::createWindowContainer(). They are no different from OpenGL-based windows in this respect. This is excellent news for 3D tooling type of applications on the desktop using QWidgets, since there is now a Vulkan-based alternative to QGLWidget/QWindow/QOpenGLWindow.
  • Vulkan support does not currently cover modules like Qt Quick, Qt 3D, Qt Canvas 3D, the OpenGL backend of QPainter, the GL composition-based QOpenGLWidget/QQuickWidget, etc.
  • Vulkan support may be introduced to some of these in the future, however this is not in scope for Qt 5.10.


So what platforms are supported?

As of Qt 5.10, the situation is the following:

  • Windows (desktop, not WinRT): when the LunarG SDK is installed, and thus the VULKAN_SDK environment variable is set, Vulkan support will automatically get enabled in the Qt build.
  • Linux (xcb only at the moment; support in the wayland platform plugin to be added later on): enabled whenever the Vulkan headers are found during configure time.
  • Android (tested on API level 23 and 24; note that the Vulkan headers (and related tools) are only present in level 24 and newer NDKs out of the box)

Note that Qt’s Vulkan support does not rely on linking to a Vulkan (or loader) library, and rather relies on resolving everything at runtime. Therefore the only hard requirement is the presence of a relatively recent set of Vulkan headers (like > 1.0.13 or so).

When it comes to the pre-built packages, we currently have some open tasks to investigate and implement support for Vulkan-enabled builds on some platforms at least. Hopefully this gets sorted out in time for Qt 5.10.

That’s it for part 1. Stay tuned for part 2, where we will start digging into the actual QVulkan classes!

The post Vulkan Support in Qt 5.10 – Part 1 appeared first on Qt Blog.

Qt for web (assembly)

So ya, I have been doing work for the up and coming Finnish company Intopalo getting Qt5 for WebAssembly using emscripten up and running. This is the 3rd Finnish company I have done work for, and the 4th Nordic company (Trolltech, Nokia, Jolla, Intopalo)

This is very much a work in progress.


There was a Qt4 version, emscripten-qt and a related Qt5 for Native Client which do similar things, and we have taken inspiration from both these projects. Thanks!

The gist of it:

We use emscripten to cross compile Qt5 into javascript and/or webassembly. We use 'incoming' from emscripten's git repo. Details how to build emsdk are here.

My working Qt5 repo is here, (the wm branch contains multi window and window decorations) while there is also an outdated WIP gerrit MR  which will get updated at some point.

This is how I configure Qt for emscripten:
 . ~/emsdk/emsdk_env.sh (to get em compiler in path)

~/depot/qt/qt5/qtbase/configure -xplatform emscripten -confirm-license -opensource -nomake tests  -nomake examples -developer-build -no-dbus -no-thread

 (no-thread is a new feature I added for this, as threading in javascript is basically non existent)

and then, use that qmake to compile a Qt app!

To run the app, in the firefox browser
emrun --browser firefox path/to/app.html

This is all bleeding edge from the emscripten compiler to the web assembly support in the browser, so your mileage may vary.

With the 'wm' branch of my github repo, multi windows and window decorations are kind of working. As well as compiling into webassembly and not just javascript asmjs.
Compiling into wasm brings much smaller download sizes, but you need to have a browser that supports it.

There is still heaps of work to do to bring it up to release state. So for now, it is still a research and WIP project, and a lot of things may or may not work. But it can run some Qt widget based apps in your (firefox) browser!

The future:

Currently there is no support for qml/qt quick. That just means we haven't tried it as our focus is currently on widgets and opengl.

Personally, I would like to see location and some sensor events, but that is for the future.

Getting started again

As you all probably know already, the crowdfunding for qutebrowser ended up being more than fully funded - thanks to everyone again!

The funds arrived on my bank account yesterday, minus some 10% fees for Kickstarter and payment processing. Yesterday also was the last day with lectures before my summer holidays!

Since Monday is a public holiday, I decided to spend some time today on sending out the stickers to everyone who doesn't have a t-shirt, and then continue next Tuesday with day 2.

Over the last few days, I also spent some time on getting QtWebEngine more ready:

For people who have t-shirts in their pledges, a survey will follow soon - I still need to sort out some things about available colors and sizes first.

If you're reading this via the Python or Qt planet, note that I won't post future minor updates there - if you want updates about what I'm doing currently (a few times per week), check the qutebrowser development blog!

CI Performance, HW and SW changes

This time I’ll cover the topics performance as well as upcoming hardware and software changes.


You have all noticed that the CI system is behaving poorly to what comes to the performance. Sometimes autotests take over 30 times longer to run compared to a normal situation. Now why is that?

We actually have different kinds of bottlenecks. One is the bandwidth with which the virtual machines (VMs) store local data to their virtual hard drives. The servers on which our virtual machines run have no local hard drives. They instead store all their data on a centralized storage called the Compellent (https://en.wikipedia.org/wiki/Dell_Compellent). So when a VM wants to store data on its virtual hard drive, the host it runs on actually stores the data on the centralized storage.

We have several generations of hardware installed, and they have different speeds on their SAN interface with which they are connected to the Compellent. As your build picks up a server, it can be a new rack server, or it can be an older generation Blade (https://en.wikipedia.org/wiki/Blade_server). Also, all the other VMs on these servers share the same bandwidth, so depending on what the other builds do, your SAN connection can be affected. Sadly, our test of prioritization these VMs, didn’t produce expected results and really didn’t much at all.

These generations of hardware and type of hardware also affect the amount of other VMs the hardware can run simultaneously.  We have Mac mini’s running our macOS builds. Those generally run 1 VM per physical Mac mini. Then we have old Blades that run around 4 VMs per Blade. The latest additions to our hardware pool are dual socket 20 core CPU server racks. Those run up to 26 VMs simultaneously. Running more on the same hardware reduces costs for us, but also increases the odds of one build affecting the next.

Another bottleneck is the Compellent itself. The storage system has 120 + 10 spare hard drives spinning at 15K RPM. However great the IOPS performance is in that system, when we decide to start 200+ VMs in the CI, it goes down to its knees. And when it does that, all builds and autotest run are affected. You could think of this as you having 2 computers at home sharing the same spinning disk.

Now that all is grim and morbid, let’s continue with the good news.

Upcoming hardware changes

We’re replacing the current hardware stack with a completely new one. The parts have arrived and are being installed as I type right now. Not only did we acquire new hardware that is faster, but we also redesigned the building concepts so that they utilize the hardware differently. The new hardware can be easily expanded and we designed the system so, that we don’t produce bottlenecks even when expanding it.

Before I go in to details, I need to explain a bit how the CI systems generally works. So, heading off on a tangent here! When developer stages a commit in Gerrit (codereview.qt-project.org), the CI picks it (or multiple commits) up. The CI or Coin as the piece of software is figuratively called, generates work items based on the data received. If let’s say the commits was for QtDeclarative, Coin now produces work items for itself to handle that QtDeclarative build on top of circa 30 different target platforms. Each of these work items depend on QtBase to be built. So now Coin also creates these circa 30 work items for QtBase. As QtDeclarative is built on top of the current qt5.git’s QtBase, it means in normal situations that QtBase has already been built previously. These artifacts have been stored by Coin and can now be reused. So instead of rebuilding QtBase for QtDeclarative, Coin simply checks its storage and links the previous builds to the current one and promptly continues with building QtDeclarative. This is the major change in how we build Qt nowadays compared to old days with Jenkins where every build always rebuilt the entire stack up to its point. You may read more about it in this blog post.

Continuing into more details. Whenever Coin starts to build something, it needs a VM for the task. We have “templates” in vSphere that represent different operating systems. They are virtual machines that have operating systems installed in them along with some basic things set up like user accounts and SSHD etc. Then they have been shut down ready to be used. Now when a build needs a VM, it clones a template VM and launches the clone. The clone is actually only a linked clone. This means that we don’t really clone anything, but only create a new virtual machine that links or points to the original one. Now, when the new clone is powered on, it _reads_ from the original template, but all changes are _written_ to its own file called the ‘delta image’. This way a new virtual machine only takes up space that’s equal to the amount of data it has written.

Going back to the template again. I said that it only contained basic things like user accounts and SSHD. A build surely needs more than that. We need Visual Studios, MINGW, CMake, OpenSSH, XCodes, MySQL etc. installed as well. Those things are ‘provisioned’. In qt5.git we have a folder structure under /coin/provisioning that contains scripts that install these things. As there is no point in running them every time for every VM, we create yet another set of templates that contain these pre-installed. We call these TIER2 images (or templates) vs TIER1 images being the vanilla distros containing only the basic things enabling us to even use them.

TIER2 images work pretty much the same way as QtBase was a dependency for QtDeclarative. Each build we trigger checks the current configurations scripts from qt5.git and makes a SHA from the folder structure. This SHA is used in naming the TIER2 image. If the content we want to install has changed, we have to regenerate a new TIER2 image. This is called the provisioning and it’s triggered automatically if the requested TIER2 image doesn’t exist.

Now, let’s go back on track and talk about the hardware changes.

The new servers have local SSD drives that work as the storage for the VMs instead of a centralized storage. This removes the bottleneck of a SAN network and reduces latencies while at it. And while being SSD drives, they are faster by design to what the Compellent used to be with its rotating discs. We still have a Compellent, but this time it’s filled with SSD drives. While the VMs use local SSD drives on the hosts themselves to store data, reading is a more complicated thing.

The TIER1 and TIER2 images described earlier are still stored centralized on the Compellent. This saves us the transferring of the images to each server serving as the host for the VMs. These TIER2 images are cloned as normal, and then the read operations point to the source. This would cause the same situation as with the old system where everything is read from the Compellent, but we are relying on caches to work in our favor here. The TIER2 images are shared via NFS, and the host OS on the server is equipped with a 500 GB NFS cache. So, whenever something is read from the TIER2, it is in fact now read from the NFS cache that’s local. All this is obviously assuming that the data has been read once previously. In practice, if a TIER2 image gets updated, the data has to be read from the centralized storage once, and then it’s in cache for the rest of the builds. We also have to remember that not the entire TIER2 image is read whenever data is read. If a build requests openssh.so, only those blocks containing the file are read.

We also need the Compellent to provide us with redundancy for critical systems and a huge data storage for data that can’t be stored distributed. Critical systems include our own infrastructure and the storage is needed for all kinds of data including our release packages, install packages, distro ISO images etc. So even if we had a good mechanism to distribute the entire TIER1 and TIER2 load to the servers themselves, currently there is no need for it and the Compellent serves this need more than well right now.

The new hardware infrastructure will include new switches and firewalls as well. And all these are being set up in new premises, so everything is new. With this we will expect a few maintenance breaks during the upcoming months where services are being handed over from one site to the other. The down times should be relatively low, since all data is being transferred beforehand and not during the down times.

Software changes

Currently Coin is using VMware’s vSphere technology to create and run VMs. That’s about to change. Our new spinal cord will be based on OpenNebula (https://opennebula.org/). The swap to this new technology will come at the same time we switch to the new facility with the new hardware. We’ve been working hard to get the robustness and reliability up, matching or even exceeding the one provided by VMware’s products. With open source non-proprietary code we can go deep into the root causes of problems and fix drivers if that’s needed to make our VMs run smoothly without hick-ups. With OpenNebula being KVM based, we can expect new distro support to be available sooner as well. No longer do we need to fall back to saying a new macOS can’t be installed because VMware doesn’t support it. Let’s hope I can hold up to this promise or claim 😉

Performance wise the comparison between VMware and OpenNebula is a bit unfair since they use different underlying hardware, but we can say that builds aren’t going to get any slower by the looks of it.

We’re also working on getting all of our distros more provision scripted. This will make it a lot easier for anyone ( yes, this includes you ) to upgrade the software that’s being run on the VMs. Anyone can access qt5.git/coin/provisioning and modify / add scripts there. Normal code review procedures apply and TIER2 images get updated.

Internally we’ve had 3 different Jenkins instances in the past. We had one for CI that got replaced by Coin a year ago. The remaining two were for release package creation, Creator builds and few others, and the second one was for RTA standing for Release Test Automation where we verified the packages to really install something and examples working etc. Those two Jenkins instances are planned to be merged with Coin at some point in time, but for the time being they are going to stay there for a while. However, we’re improving the backend of how they receive their VMs. They currently compete with Coin in getting hardware resources. In the next weeks, this is going to be changed so that Coin creates these VMs. This takes away the race conditions between two back ends, but also gives our Jenkins instances “support” for OpenNebula VMs. Even if this does not show up directly to you as CI users, it should show up with slightly more reliable VM dedication, more effective cleanup of VMs, and at least from the technical perspective we should be more capable of producing packages faster.


The post CI Performance, HW and SW changes appeared first on Qt Blog.

KDAB contributions to Qt 5.9

Qt 5.9 has just been released!

This release marks two important milestones for the Qt Project. The first is that now the Qt 5 series has had more releases than any other Qt version ever (the last release of the Qt 4 series was Qt 4.8). The second milestone is that Qt 5.9 will be a Long Term Support release, therefore providing to many users a stable foundation to build their applications upon.

KDAB has been a significant contributor to this release, as shown by the number of commits by KDAB developers merged into Qt. In this blog post I will showcase some of the most outstanding contributions to Qt 5.9 developed by KDAB engineers. continue reading

The post KDAB contributions to Qt 5.9 appeared first on KDAB.

Qt 5.9 released

I’m happy to let you all know that Qt 5.9.0 has just been released. A lot of work has been put into it, making Qt 5.9 the best Qt version we have developed so far.

With Qt 5.9, we have had a strong focus on performance and stability. We’ve fixed a large number of bugs all across Qt, and we have done a lot of work to improve our continuous integration system. This will make it a lot easier for us to create new releases (both patch level and minor releases) from 5.9 onward.

We’ve also added automated performance regression testing to our testing infrastructure, something that will allow us to continuously monitor our work on improving the performance of Qt. Please have a look at the separate blog post for more details.

The new configuration system used in Qt Lite has received many bug fixes, also here, you can find more detailed information in a separate blog post.

Long term supported

One major decision we have taken is to make Qt 5.9 another long-term supported (LTS) release. The previous LTS release, Qt 5.6, is starting to show it’s age, and many users have been asking for a more up to date version of Qt that they can use as a basis for long running projects.

Some of the major changes since Qt 5.6 include more than 2000 bug fixes all over Qt. Additionally, we are now using a C++11 compliant compiler with Qt which has allowed us to modernize our code base. We have also added the Qt Lite configuration system and made significant updates to our graphics architecture. This is in addition to all the other new things that have been implemented in Qt 5.9, explained in the following sections.

As an LTS release, Qt 5.9 will be supported for the next three years to come.

With our improvements on the CI and releasing infrastructure, we are convinced that we will be able to provide you with much more frequent updates and patch level releases for Qt 5.9 than we are able to do for the Qt 5.6 series. As a long term supported release, we will provide you with frequent updates in the first year. After the first year, we will gradually get more and more strict on the changes that will happen in the branch, so as a result, patch level releases are expected to happen somewhat less frequently for the second and third year.

We will as promised also continue to support Qt 5.6, but we strongly recommend everyone starting new projects to use Qt 5.9 as there are a lot of improvements across the board that will be of huge advantage to you.

Lots of new functionality

Even with our focus on performance and stability, we have managed to add more new features into Qt 5.9 than I can mention in this blog. For a more complete list have a look at the ‘New Features’ page in our wiki.

Here are some of the highlighted new features.

Core and Networking

Quite a few new features have been added in the Core and Networking modules. Starting at the base, Qt Core has two new classes. The first class, qfloat16 abstracts 16-bit floating point numbers, as these nowadays are increasingly more important for inter-operation with APIs which make use of the GPU. In addition, a new QOperatingSystemVersion class has been added to conveniently test for the operating system and version your application is running on.

Qt Network has gained support for HSTS (HTTP Strict Transport Security), improving security on HTTPS connections through QNetworkAccessManager.

Our NFC support in Qt NFC has seen some very nice improvements for Android, and Qt Web Sockets can now use external TCP sockets. Classic Bluetooth on WinRT and Bluetooth peripherals on Android are now both supported.

Qt Gui and 3Dqt3d

Qt GUI has gained a shader cache, that can cache compiled versions of OpenGL shader programs, and we have added support for Compute Shaders. The OpenGL paint engine does now work with OpenGL Core profiles as well.

An enormous amount of work has been done with Qt 3D. Together with the functionality we already had in Qt 5.8, we now have a fantastic 3D engine in Qt 5.9. You can find all the details in a separate blog post by our partner KDAB.

Qt QML and Quick

Quite a bit of work has been put into improving the QML and JS engine for Qt 5.9. We have added a completely rewritten garbage collector, offering better performance and reducing memory fragmentation in the JavaScript heap. The new collector also provides a better basis for further enhancements to our memory management in upcoming Qt versions.

Qt 5.9 also comes with a brand new QML caching infrastructure, offering similar benefits to our users — just like the commercially available Qt Quick Compiler, but in a much more transparent way. The new infrastructure has two modes of operation. In the default mode, the caching infrastructure creates a binary cache of your QML files at the first start-up of the application. Optionally, you can also pre-create that cache at application build time, achieving similar performance and startup time benefits as with the Qt Quick Compiler. Additionally, the new caching infrastructure does not bind your application to a specific patch level version of Qt, as the binary caches are versioned and will get regenerated if required.

Also, a lot of work to improve performance and reduce memory consumption has been done in the engine, making this a significant upgrade compared to our previous Qt 5.6 LTS release.

Qt Quick now makes use of the new OpenGL shader cache added in Qt GUI, improving application startup times. We added an image provider that can share image data between processes, and a new OpenVG backend, allowing it to run on hardware that only has 2D hardware acceleration support.

Qt Quick Controls 2 has added more new features than I can mention here, please have a look at the separate summary blog post, which links to all the details and blog posts on what has been added in Qt Quick Controls since Qt 5.7.

Qt Location and Positioning

For this release, Qt Location has received quite a few new features. We’ve added support for tilting and rotating maps, both through the APIs and through touch gestures. Stacking of maps has been improved, it’s now a lot easier to add overlay items to maps, and we improved the support for blending in copyright notices on the maps.

An entirely new plugin adds support for Mapbox, using their OpenGL based map rendering engine.


A couple of other visual improvements have also happened, like using lower resolution tiles to approximate tiles that are still missing at a higher zoom level until those are downloaded.

On iOS, we improved Qt Positioning, so that it now can collect data even when the application is in the background.

Other modules

Many other modules have also been updated. Most notably, Qt Webengine is now using Chromium 56. Qt Virtual Keyboard now supports external keyboard layouts and many other cool new features.


Qt Gamepad has graduated from Tech Preview status to being fully supported in Qt 5.9. We’ve also added Qt Remote Objects as a new module in Technology Preview status.

There have been significant changes to Qt Wayland that are described in a separate blog post.

Of course, Qt 5.9 also comes with a brand new version of Qt Creator with many great new features. The Qt Quick Designer now contains a built-in code editor, and we now have a completely rewritten the cmake integration. For further details, have a look at the separate blog.

Platform changes

Qt 5.9 adds support for two new platforms. It now supports QNX 7.0, the latest version of the QNX operating system. We have also added support for the INTEGRITY OS, details about this are again in a separate blog post.

Finally, we added support for compiling Qt in a size optimized mode (-Os on GCC), saving around 5-20% in binary size for the Qt libraries and your applications.


Finally, I’d like to thank all the people who have contributed to this release. While you can see and follow all the people contributing code through patches to our git repositories, a lot of additional work has happened more invisibly behind the scenes, for example by working on our CI and releasing infrastructure or helping to create collateral and content for the web pages.

I hope you’ll all enjoy this release. You can get it from the usual places, either through your Qt Account or from our download page. Please also don’t forget to give us your feedback, and write a bug report (if you should find one), so that we can improve the 5.9 series even further in upcoming patch releases.

The post Qt 5.9 released appeared first on Qt Blog.

Performance Improvements with Qt 5.9 LTS

Qt 5.9 LTS improves Qt Quick and QML performance significantly, especially with Linux on ARM. We have worked hard to improve the performance in multiple areas: within the QML engine, Qt Quick graphics, QML Compiler and in the Qt Quick Controls, to name some examples. Performance has improved significantly across all areas, with some items being several times faster than with our previous long-term supported release Qt 5.6 LTS.

We are regularly running several different kinds of performance tests to see how the various optimizations work across different platforms. Some of these results are visible at testsresults.qt.io, while some tests have not been automated yet. Whenever possible, we are aiming to optimize the performance of all supported operating systems and CPU architectures. For readability and because Linux on ARM has been an area of particular focus with Qt 5.9 LTS, it is the one discussed in this post. Typically, the other platforms have received roughly similar improvements.

Qt Quick Application Startup Time

Startup time of a Qt Quick application is often critical in the embedded space. This is true for small single-process embedded systems, as well as for more complex multi-process devices. We have offered a commercial-only tool called the Qt Quick Compiler since Qt 5.3 to improve the startup time by leveraging the C++ compiler to compile QML into a normal C++ binary. Between Qt 5.6 LTS and Qt 5.9 LTS, the performance of the QML engine has improved with each new Qt release, resulting in improved application startup time. Qt 5.8 introduced QML caching, which makes second and subsequent runs of the applications to be faster. Qt 5.9 also offers a possibility to pre-populate the cache to reach improved performance already with the first run. With the Qt Quick Compiler, the first run is also already fast.


Each application has unique characteristics so the exact benefit in startup time for using Qt 5.9 LTS and/or the Qt Quick Compiler will vary. Typically, the more QML used, the bigger the improvement is. In Qt 5.9 LTS we offer two alternative options: the commercial-only Qt Quick Compiler and a new tool to populate the cache ahead-of-time, which is available for both open-source and commercial users. The performance and reduced startup time are in practice the same with both approaches in Qt 5.9 LTS.

When comparing the startup time for the same Qt Quick application with Qt 5.6 LTS without the Qt Quick Compiler to the startup time of Qt 5.9 LTS using the Qt Quick Compiler (or populated cache), the improvement is a whopping 60% on NXP i.MX6. When using the commercial-only Qt Quick Compiler of Qt 5.6 LTS the improvement in startup time is 54% (compared to Qt 5.6 LTS without the Qt Quick Compiler in use). Comparing the startup times of Qt 5.6 LTS and Qt 5.9 LTS when both are using the Qt Quick Compiler the improvement is 14% on NXP i.MX6.

The application used for the tests was the Qt Quick Controls 1 gallery and the tests were run with Linux on NXP i.MX6 and NVIDIA Tegra X1. We used the Controls 1 example because they are much heavier than Controls 2, thus better resembling a typical real-life Qt Quick application. For more measurements of Qt Quick application startup times, please check out the earlier blog post. For instructions to further optimize startup time of a Qt Quick application, please read the second post of our earlier fastboot blog series.

Qt Quick Controls Performance 

Qt 5.6 LTS features Qt Quick Controls 1 while Qt 5.9 LTS features the Qt Quick Controls 2 fully supported. The main design principle of Qt Quick Controls 2 has been performance, as can be seen already from the blog post announcing them. From the very beginning, the key focus area of the new Qt Quick Controls 2 has been for embedded devices and systems. However, these can equally well be used on all supported platforms. Compared to Qt Widgets or Qt Quick Controls 1, the key difference of Qt Quick Controls 2 is that they do not adapt to platform style. We do offer multiple different styles for Qt Quick Controls 2 and it is easy to make your own style as well. From an architectural viewpoint, the key difference of Qt Quick Controls 2 is that they leverage C++ for everything that can be done with C++ and offer just the QML API for applications to use.


As illustrated in the graph above, the performance improvement is huge (note: the higher the bar, the better the performance is). We used NXP i.MX6 running Linux for the measurements. For some of the controls the performance is 14x better than before, and on average the performance has been improved 6x comparing Qt 5.9 LTS with Qt Quick Controls 2 to Qt 5.6 LTS with Qt Quick Controls 1. To benefit from the improved performance, the application needs to be ported to use Qt Quick Controls 2. This is typically quite straightforward and Qt Quick Controls 2 offers most of the common controls. Before porting, please check the documentation, as some controls, such as TableView, are not currently available with Qt Quick Controls 2.

Shader Cache 

Qt 5.9 LTS introduces a new feature to cache OpenGL shaders to disk after the first run, as explained in the blog post introducing the shader cache. If your Qt Quick application is using OpenGL shaders, which is quite often the case, it will achieve a significant improvement in startup time compared to earlier versions of Qt. When comparing the performance of Qt 5.6 LTS to Qt 5.9 LTS using the same Qt Quick application with 10 shaders, we can see a significant improvement in the initialization time of the shaders. Some of the performance improvement observed in the measurement is due to the overall improvements in the graphics performance, but most of the improvement can be attributed to the new shader cache feature.


Qt 5.9 LTS is a whopping 7x faster than Qt 5.6 LTS on startup with the same exact Qt Quick application running the same hardware. Just like the previous measurements described in the blog post, this test has also been conducted using NXP i.MX6 running Linux. The performance improvement is dependent on the hardware and especially the GPU plays a major role. Based on our measurements there are significant improvements with every piece of hardware we have tested – including ones that implement cache feature already in the OpenGL driver.

Memory Footprint Improvements

In Qt 5.8 we introduced a new configuration system and made other improvements to reduce the binary size of the Qt framework libraries used for different applications. This was developed as part of the Qt Lite project, which focused specifically on reducing the application size. With Qt 5.9 LTS we have further polished and tuned the available configurations so that more and more different kinds of applications can reach their minimal Qt configuration. Reducing the size of a Qt 5.6 LTS application is possible mainly by just using the modules needed by the application and statically linking the binary. Because of dependencies within the Qt framework, the linker is not able to reach as small binary size as it is possible with Qt 5.9 LTS using the new configuration tool.


We used a simple, but non-trivial, Qt Quick application (samegame) to compare the needed binary size of the application itself as well as all the Qt libraries it needs. With Qt 5.6 LTS the application requires 24,5MB when linking dynamically. Using static linking, the size is reduced to 13,8MB (still using Qt 5.6 LTS). Leveraging the new configuration tool in Qt 5.9 LTS and with other Qt Lite improvements, the exact same application only needs 5,4MB when static linking is used. Percentage-wise, the Qt 5.9 LTS binary size of the application is 61% smaller than the same application with Qt 5.6 LTS and static linking – without losing any functionality or making any changes to the application.

Improvement in JavaScript Performance 

With the improvements in the QML engine in Qt 5.9 LTS the performance of JavaScript execution has also improved. If the Qt Quick application leverages JavaScript, there is a huge improvement in performance compared to Qt 5.6 LTS, especially on 64-bit ARM. One example of heavily leveraging JavaScript is using three.js on top of Canvas 3D, and smaller amounts of JavaScript are often used in Qt Quick applications.


The measurements are done with v8-bench, which can be found in the qtdeclarative repository. Additional measurements are available at testresults.qt.io. With the v8-bench performance benchmark results of Qt 5.6 LTS compared to Qt 5.9 LTS, the improvement on 32-bit ARM is 16%, but on 64-bit ARM the improvement is a whopping 302% (i.e. 4x improvement). The reasons for the huge improvements are that Qt 5.9 LTS fully supports 64-bit ARM processors combined with the improvements in the QML engine.

Overall Qt Quick Performance Improvements 

The examples above are just some of the highlights from many improvements we have done to the performance of Qt Quick in Qt 5.9 LTS. We have tuned multiple individual areas and optimized the execution paths within the Qt framework. It is important to note that we have also worked hard not to regress in any areas. To avoid regressions, we are regularly running a comprehensive Qt Quick benchmark suite called Qmlbench. With the Qmlbench tool we can see the performance of the most commonly used Qt Quick functionality as well as the functionality that is used less frequently. For more details, please review the thorough explanation of how we are using Qmlbench to avoid regressions.


When comparing Qt 5.6 LTS and Qt 5.9 LTS in the same environment with the comprehensive Qmlbench measurements, we can see  that some areas improved up to 130% as shown in the graph above. Especially layout and complex text performance has improved drastically. The average improvement of Qt 5.9 LTS compared to Qt 5.6 LTS in all Qmlbench tests is 14% (measured on Linux). Despite which functionality is used, the improvement in performance of a Qt Quick application running Qt 5.9 LTS compared to Qt 5.6 LTS is clear and tangible for most applications.


In this blog post, I summarized some of the multiple performance improvements available with Qt 5.9 LTS. Compared to Qt 5.6 LTS, the performance of the same application running on Qt 5.9 LTS is significantly higher. Without making any changes to the application, except for compiling it for the new Qt 5.9 LTS, the performance is significantly improved. Ranging from improved application startup time and smaller footprint through to increased graphics performance, Qt 5.9 LTS is a major step forward performance-wise. Taking some of the new features, such as Qt Quick Controls 2, into use even furthers the performance improvements available with Qt 5.9 LTS.

Interested in taking a closer look? Qt 5.9.0 has been released today. You can get it with your online installer, from the Qt Account or from the Qt Downloads page (for open-source users).

For more details of Qt 5.9 LTS, please check the Qt 5.9 LTS release blog post.


The post Performance Improvements with Qt 5.9 LTS appeared first on Qt Blog.