Boot to Qt on embedded HW using Android 7.0 and Qt 5.8

One can have real pain trying to create a demo setup or proof-of-concept for an embedded device. To ease the pain Qt for Device Creation has a list of supported devices where you can flash a “Boot to Qt” image and get your software running on the target HW literally within minutes.


Back in 2014 we introduced a way to make an Android device boot to Qt without the need of a custom OS build. Android has been ported to several devices and the Android injection method made it possible to get all the benefits of native Qt applications on an embedded device with the adaptation already provided by Android.

The Android injection was introduced using Qt versions 5.3.1. whereas the supported Android versions were 4.2 and 4.4. It is not in our best interest that anyone would be forced to use older version of Qt, nor does it help if the Android version we support does not support the hardware that the developers are planning to use. I have good news as the situation has now changed.

Late last year we realized that there still is demand for Android injection on embedded devices so we checked what it takes to bring the support up to date. The target was to use Qt 5.8 to build Boot to Qt demo application and run it on a device that runs Android 7.0. The device of choice was Nexus 6 smartphone which was one of the supported devices for Android Open Source Project version 7.0.0.

The process

We first took the Android 7.0 toolchain and updated the Qt 5.4 Boot to Qt Android injection source code to match the updated APIs of Android 7.0. Once we could build Qt 5.4 with the toolchain, it was time to patch the changes all the way to Qt 5.8.
Since Qt version 5.4 there has been improved modularity in Qt and it became apparent during the process, e.g. the old Surfaceflinger integration was replaced with a platform plugin.

The results can be seen in the videos below.

The Boot to Qt Android injection is an excellent way to speed up the development and get your software to run on target hardware as early as possible. If you want to know more about the Boot to Qt and Android injection, don’t hesitate to contact us.

The post Boot to Qt on embedded HW using Android 7.0 and Qt 5.8 appeared first on Qt Blog.

Cutelyst 1.4.0 released, C100K ready.

Yes, it's not a typo.

Thanks to the last batch of improvements and with the great help of jemalloc, cutelyst-wsgi can do 100k request per second using a single thread/process on my i5 CPU. Without the use of jemalloc the rate was around 85k req/s.

This together with the EPoll event loop can really scale your web application, initially I thought that the option to replace the default glib (on Unix) event loop of Qt had no gain, but after increasing the connection number it handle them a lot better. With 256 connections the request per second using glib event loop get's to 65k req/s while the EPoll one stays at 90k req/s a lot closer to the number when only 32 connections is tested.

Beside these lovely numbers Matthias Fehring added a new Session backend memcached and a change to finally get translations to work on Grantlee templates. The cutelyst-wsgi got --socket-timeout, --lazy, many fixes, removal of usage of deprecated Qt API, and Unix signal handling seems to be working properly now.

Get it!

Hang on FreeNode #cutelyst IRC channel or Google groups:!forum/cutelyst

Have fun!

Qt 5.5.1-2 for Wind River® VxWorks® Real-Time Operating System Released

The Qt 5.5.1-2 release for VxWorks Real-Time Operating System (RTOS) release supports the new VxWorks 7 release SR 0480 (September 2016) on ARM-v7 with updates in the Qt Base, Qt Declarative and Qt Quick Controls modules. For full list of changes, please see the change log.

To learn more about Qt 5.5 for VxWorks, please check out:

Existing licenses of Qt for VxWorks can download the new release from their Qt Account web portal and run it on top of the SR 0480 (September 2016) release of VxWorks 7 RTOS. If you wish to conduct a technical evaluation, please contact us to request an evaluation.

If you are planning to visit Embedded World in Nürnberg 14th – 16th March 2017, please come to see Qt at Hall 4, Stand 4-258 and Wind River at Hall 4, Stand 158.

Qt will also be in Wind River’s booth at HIMSS 2017 Booth#7785-21 showcasing a Qt for Medical IoT Heart rate monitor using VxWorks7 and Helix Cloud on i.MX6 built with Qt. Learn more.

VxWorks real-time operating system has been building embedded devices and systems for more than 30 years and powers more than 2 billion devices. To learn more about VxWorks, please visit the VxWorks webpage or contact Wind River.

The post Qt 5.5.1-2 for Wind River® VxWorks® Real-Time Operating System Released appeared first on Qt Blog.

QtWebKit: I'm back!

Hello world!


Five years have passed since the last entry in this blog, and almost 3 years since infamous "Changes in QtWebKit development" thread at Fortunately, we've made quite different kind of change in QtWebKit development lately, and it is much more exciting.

QtWebKit is back again!

If you were following QtWebKit development after 2013, you know that actually development have never stopped: each release was getting a bunch of bugfixes and even brand new features. However, WebKit engine itself has not been updated since Qt 5.2 release. That's why it didn't support recent changes in Web standards that happened after 2013, including: new JavaScript language standard ES2015 (also known as ES6), as well as improvements in DOM API and CSS.

However, things have changed in 2016, and now we have revived QtWebKit! Core engine code was updated to it's actual state, and as a result we (and you!) can use all improvements made by WebKit community during these 3 years without any changes in code of existing Qt applications!

You may be wondering, why anyone would like to use QtWebKit in 2016, when shiny new QtWebEngine is available? There is a number of reasons:
  • When used in Qt application, QtWebKit has smaller footprint because it shares a lot of code with Qt. For example, it uses the same code paths for drawing and networking that your regular Qt code uses. This is especially important for embedded systems, where both storage space and memory are scarce resources. It's possible to go further and cut away features which are not crucial for your application, using flexible configuration system of WebKit.
  • On Linux QtWebKit uses GStreamer as a default media player backend. This means that application users will be able to use patent encumbered codecs (if this is legal in their areas) without getting you (as application developer or distributor) into legal troubles.
  • Lots of existing open source applications depend on QtWebKit, but without security updates their users are left open to vulnerabilities. The are only two ways to work around this problem: port applications away from QtWebKit (which is often a hard task because QtWebKit allows much deeper integration with application code than alternative solutions), or update QtWebKit itself, which makes these large porting work unnecessary.
  • QtWebKit is more portable than Chromium: it can run on any CPU architecture supported by Qt and on virtually any Unixish OS (as well as Windows and Mac). The only requirement is a C++11 compiler.
  • Non-interactive user agents like PhantomJS or wkhtmltopdf don't gain any benefits from multi-process architecture, so using single-process WebKit 1 API allows them to have less resource footprint and simpler flow of execution.

    Q: I've heard that WebKit engine is not relevant anymore, since the crowd is working on Blink these days!

    A: This is not true. Despite of the Google departure, WebKit remains on of the leading browser engines, and is progressing at a fast pace. If you don't believe, read on! Also you may want to read release announcements of Safari Technology Preview and WebKitGTK, which higlight other WebKit features under development.

    Now let's see what can we do with QtWebkit in 2016!

    JavaScript engine improvements and ES2015 status


    Most of features are supported now (QtWebKit 5.6 has 10% rating). Note that WebKit is the first web engine providing proper tail calls, which means you can enjoy functional programming without unnecessary stack growth in tail recursion!

    WebKit gained new tier of JavaScript JIT compilation, called FTL. First implementation was based on LLVM compiler infrastructure, but now we are shipping B3 compiler which is more lightweight, does not pull in additional dependencies, and also compiles faster. FTL usually gets activated for computationally-intensive JS code, and is especially useful for running native code compiled to ASM.js.

    Code produced by JavaScript JIT now uses normal C stack, reducing overall memory usage and fragmentation.

    JIT compiler now uses background threads, so compilation does not block execution of other code.

    New (and old) CSS properties

    Web standards evolve rapidly, and more and more CSS properties find their way into specification. Most of them have already been available for a long time, but used -webkit vendor prefix as they were non-standard extensions at a time of their introduction, and now they (finally!) have formal description which all vendor are obliged to follow (though sometimes standardization process changes behavior of old properties). Standardized properties are available without vendor prefixes, and web page authors start actively using these new spelling.

    Unfortunately, sometimes they break compatiblity with old browsers, which implement prefixed properties, with disastrous consequences. Here are screenshots of site that uses unprefixed flexbox properties, defined in CSS3:

      QtWebKit 5.6

      QtWebKit TP3

      CSS Selector JIT

      Besides JavaScriptCore, WebKit now features yet another JIT compiler. Its aim is to speed up application of CSS style sheet to elements of page DOM, so called style resolution. Average performance gain is about 2x, however for complex selector and/or pages with lots of DOM nodes gain may be substantially larger.

      Selector JIT also makes querySelector() and querySelectorAll() faster, but speed up factor may differ.


      This is new CSS property, allowing page author to create "drop cap" effect without much hassle. In order to make this effect work correctly with calligraphic fonts, Qt 5.8 (not yet released) is required.

      Other improvements

      • Responsive images support (<picture> element, srcset and sizes attributes)
      • ellipse()method in Canvas API
      • CSS selectors ::read-writeand ::read-only
      • HTML <template>element 
      • APNG images

      We also support following web features with experimental status and only for GStreamer media player backend:
      • Media Source Extensions
      • WebAudio

        The path ahead

        Unfortunately, porting Qt-specific code to the new WebKit is not always easy, and we had to disable certain features until all code behind them is ported properly. So far, following prominent features are not yet working:
        • QML API
        • WebGL and CSS 3D transforms
        • Accelerated compositing
        • Private browsing
        However, don't be discouraged! Work is in progress and we hope to get these feature available soon. But we are short on manpower so we cannot work on many things in parallel. If you want to get your favorite feature ready sooner rather than later, please join our project. We have a lot of work to do, most items don't require any prior knowledge of WebKit, and some even don't require you to know C++ (yes, there is work for those of you who know only HTML + CSS + basic JavaScript, or only Python). Another way to help us is to report bugs you have found, or help to track down known issues.

        You can follow development of QtWebKit at GitHub repository; however if you want to obtain get bleeding edge sources, use another repository - the latter one is much smaller than original, but still contains all files required to build QtWebKit. See our wiki for build instruction and additional information about the project.


        Today is 10 years since the first chunk of QtWebKit code have been merged into WebKit repository. See for more details.


        Technology Preview 3 is now available: release notes, tarball. Binaries for Windows and macOS will be uploaded a bit later.

        Update 2

        Technology Preview 5 is available now. It includes binaries for Windows (MSVC, MinGW), macOS, and Linux, that are fully compatible with official Qt 5.8.0 SDK.

        SpeedCrunch 0.12 Released

        Almost 3 years and 700 000 downloads later, here's the core new features of this release:
        If you're curious, check out the complete list of enhancements and bug fixes. Or go straight to the downloads page. For better productivity, learn about all the user interface quirks at your disposal.

        MacOS users: please note that a download is not yet available for you. If you can help us with that, please get in touch. (download is now available, thanks to Samuel Gaist).

        Don't forget to report issues or request new features in our tracker. See more ways to contribute in the Help menu on the new website. Please help us release 1.0 as quickly as possible. Have a look at what's planned already.

        Massive thank you to TeyutPol WelterFelix KrullHadrien, all the translators at Transifex, and the folks over at Portable Apps (for representing a nice chunk of our user base).


        Missed the Qt World Summit 2016 sessions?

        The Qt World Summit 2016 sessions recordings are now available on-demand! Whether you had the chance to see us at #QtWS16 live last year or missed us, you can watch experts covering everything from the Future of technology, HMI strategy planning and project management to deep dives into user experience design for software engineers and much more.

        There was a lot happening on-stage by a myriad of speakers including Qt company experts, industry leaders, and our more than capable partners–and you can relive those moments.

        Recommended categories:

        • Keynotes – watch how we kick-started #QtWS16!
        • Deep tech and UI/UX – get the tips & tricks from the Qt experts
        • Built with Qt – check out the buzz around Qt in the industry

        So pull up a chair, grab a beverage and enjoy the show!

        And in case you missed it, see what #QtWS16 attendees from Ubuntu, Tableau, and LG had taken away about Qt:

        To stay tuned for Qt World Summit 2017 updates, subscribe for the newsletter at

        The post Missed the Qt World Summit 2016 sessions? appeared first on Qt Blog.

        Glowing Qt Charts

        Have you ever had the need to visualize data graphically and add some ‘wow’-effect to it? I’m currently helping out with the development of a demo application, where we have some charts to visualize data received from sensors. Naturally, the designer wants the charts to be visually appealing.

        At the beginning we had basic graphs to show the data, one of them being temperature. We used LineSeries QML type from Qt Charts with dynamic for this.

        Temperature represented as LineSeries.

        Now to make the graph more polished we decided to hide the labels and the grids drawn to the chart and make the background transparent. This way we had only the series drawn to the area reserved for the graph. To achieve this we modified our ChartView with two axis and a series to the following:

        ChartView {
            id: chartView
            backgroundColor: "transparent"
            legend.visible: false
            ValueAxis {
                id: valueAxisX
                min: 0
                max: maxNumOfTempReadings + 1
                visible: false
            ValueAxis {
                id: valueAxisY
                min: minimum
                max: maximum
                visible: false
            LineSeries {
                id: avgTempSeries
                axisX: valueAxisX
                axisY: valueAxisY
                color: chartColor

        But having just the series was no fun. With the main background of the application and the temperature values we had a chart that looked like in the following picture.

        Temperature chart without effects.

        As the design specification had some glow on elements in the UI, we decided to give a try to some graphical effects QML has to offer, more precisely the Glow effect. We added the Glow element to the same level with the ChartView (Glow and ChartView elements are siblings).

        Glow {
            anchors.fill: chartView
            radius: 18
            samples: 37
            color: "#15bdff"
            source: chartView

        With the above code it was very easy to add some glow to the chart series. The same chart as shown in the beginning with the mentioned changes and some additional elements ended up looking like in the following picture.

        Temperature graph with a glowing series.

        Want to spice up your charts? Go and give it a try, it’s really easy.

        The post Glowing Qt Charts appeared first on Qt Blog.

        Native look and feel

        by Richard Moe Gustavsen (Qt Blog)

        We know that many Qt users want controls styled with a native look-and-feel. But offering that on platforms with no public styling API, is hard. A classic approach is to take snapshots of the native controls, tweak them, and use them as foreground or background in our own controls. Which is somewhat OK for static appearances. But when animations and transitions are involved, static pixmaps will only take you half the way. And since an OS can change style from one update to the next, taking snapshots runtime is risky. Using pre-grabbed snapshots is also something we don’t do because of legal considerations.

        Since December last year, the controls team has been researching a bit small scale on a new project to offer controls with true native look-and-feel. The aim is to do the alternative to the above standing, and explore how feasible it would be to wrap actual native controls into a cross platform Qt API. Such ideas is nothing new of course, and have been discussed many times, at least internally. One of the problems is that different platforms can vary quite much API-wise, especially for more complex controls like tab-, and split views, with some having a rich API, while others are more limited. And unifying that into a common useable Qt API is a challenge.

        Currently we have prototyped a set of controls, together with a plugin-based framework and a few backends for testing (uikit, appkit, android). The API is small and strict so that it can be realized on all supported (and future) platforms. As such, the controls become rather black box, since we cannot make assumptions on how they are implemented by the backends. Still, there will be times when you need to detail how your application should work on a specific platform. For that reason we plan to open up, and factor out, the various backends into separate libraries that can be accessed directly. Those libraries will wrap parts of the native APIs more closely, and offer building blocks specific to the platform, or controls with a broader set of functions and properties. They will be more open than the common controls, giving access to the native controls they wrap, to let you dig into to native development whenever you need to fill gaps that falls outside our own scope. In the end, it should be easy and straightforward to mix cross-platform controls, platform-specific controls, and native code in your application.

        I’ve mentioned “APIs” a couple of times. This of course includes QML. But we also plan to offer direct access to the underlying C++ libraries, making it easy to extend the API, and write applications using C++ only. That way you can choose whether you want to use QML, C++, or a combination.

        Here is a snippet showing how things look so far. The app mixes a couple of cross-platform controls (common controls) together with a control directly from the AppKit backend.

        import QtQml 2.0
        import Qt.CommonControls 1.0 as Common
        import Qt.AppKitControls 1.0 as AppKit
        Window {
            id: window
            visible: true
            Common.Button {
                id: button
                x: 20
                y: 20
                text: "Click me"
                onClicked: text ="You clicked me!"
            Common.TextField {
                id: textField
                placeholderText: "TextField"
                x: 20
                y: button.bottom + 8
            AppKit.SearchField {
                placeholderText: "Search"
                x: 20
                y: textField.bottom + 8

        The next snippet shows the same app, but this time in C++

        int main(int argc, char *argv[])
            QGuiApplication app(argc, argv);
            QCommonWindow window;
            QCommonButton commonButton(QStringLiteral("Click me"), &window);
            commonButton.move(20, 20);
            QObject::connect(&commonButton, &QCommonButton::clicked, [&commonButton](){
            QCommonTextField textField(&window);
            textField.move(20, commonButton.bottom() + 8);
        #if defined(Q_OS_MACOS)
            QAppKitSearchField searchField;
            searchField.move(20, textField.bottom() + 8);
            NSSearchField *nsSearchField = searchField.nsSearchFieldHandle();
            nsSearchField.placeholderString = @"Search...";
            return app.exec();

        As mentioned, we plan to keep the API rather strict. The common controls will only contain the basics, with few, or no possibilities for tweaking the style, catching internal events, or overriding default behaviour. You basically get native controls with native look, feel and behaviour. If you, on the other hand, need custom styling, or your own custom controls, Qt offer solutions like QtQuickControls2, or Widgets, for that already. Our current thinking is that this module will be something for Qt6.

        The post Native look and feel appeared first on Qt Blog.

        Release 2.10.0: New App Showcase, Multiplayer & Multi-Language Improvements, Qt 5.8

        V-Play 2.10.0 is here and it includes all the new features of Qt 5.8, as well as Qt Creator 4.2.

        It adds a new Showcase App which combines all V-Play app demos in one application. It includes some of the most common app components used today and you can access it’s full source code from your V-Play installation. You can read more about it here!

        You can check out these features by downloading the Showcase app for free. You can get it for Android from the Google Play Store or for iOS from the App Store.

        The update also includes a number of new V-Play Multiplayer features to improve matchmaking. Check out the details here and find out how you can now add and remove players during live games.

        As well as that, V-Play 2.10.0 improves support for language localization within mobile apps and games. You can now develop your apps and games using your default language and V-Play will automatically find the best translations for your text!

        V-Play developers can find details on how to successfully update to Qt 5.8 here.

        New V-Play developers can sign-up now and get the tool for free!

        Update V-Play Now!

        Qt 5.8 and Qt Creator 4.2 Support

        V-Play 2.10 lets you use features from the newly released Qt 5.8 and Qt Creator 4.2. This update includes a wide-ranging selection of new features, including Qt Quick Controls 2.1. Check out this video to learn more about the update:

        Along with these new Qt features, V-Play 2.10.0 gives you advanced language support and new in-app purchase features.

        Internationalization Support

        V-Play apps and games now make it easier to support multiple languages. Create your app using default texts and easily support different countries and languages by enabling translations.

        The correct translation is automatically chosen based on the detected system language of the device. To manually switch the language at runtime, use the new GameWindow::settings.language property. This feature can be added to your app or game in minutes with this block of code:

        GameWindow {
           Scene {
             Column {
               // create a localizable text with qsTr() and
               // make it dynamically change by binding to translation.language
               Text {
                 anchors.horizontalCenter: parent.horizontalCenter
                 text: qsTr("Hello World") + translation.language
               // toggle language between german and english on button press
               ButtonVPlay {
                 readonly property bool isEnglish: settings.language === "en_EN"
                 text: "Switch to " + (isEnglish ? "German" : "English")
                 onClicked: settings.language = isEnglish ? "de_DE" : "en_EN"

        You can read How to Make a Multi Language App or Game with V-Play for more information!


        You can now use the SyncedStore component together with the Soomla Plugin to synchronize your in-app purchases across devices.

        This new feature allows users to purchase goods in your game or app as before, but additionally uses the V-Play Game Network WebStorage to synchronize the balance of your virtual goods and currencies between the user’s devices.

        How to Update to Qt 5.8

        Make your switch to the latest versions of V-Play and Qt as smooth as possible with these guidelines:

        • After updating, open the MaintenanceTool in your V-Play SDK installation folder and remove Qt 5.7 from your installed components. Since V-Play is not compatible with Qt 5.7 anymore, it is best to remove these kits.
        • Qt Creator should automatically detect the kits for Qt 5.8, which you can use to build your V-Play projects.
        • To enable one of the new Qt 5.8 kits, click “Projects” on the left side of Qt Creator and enable your desired kit in the tree below “Build and Run”

        qt creator

        • Qt 5.8 for Android requires the latest Android NDK. You can download the NDK here.

        Showcase Component App Update

        The updated Component Showcase Demo App combines the most important V-Play Apps features in a single app with native user experience (UX) and fluid UI animations.

        iOS                                                                                        Android

        apps-demo-showcase-ios-1  apps-demo-showcase-android-1

        You can use the showcase app to see how V-Play Apps handles:

        • Theming and native platform styles
        • Native dialogs, camera/image picker and share features
        • Embedded maps and GPS positioning
        • Embedded video, audio and WebView
        • Shader effects and fluid animations
        • Native styled controls and Qt Quick Controls
        • Local storage, app navigation, lists and sections

        Download the Showcase Component App

        The V-Play Showcase Component app is one of the easiest ways for you to see the power of V-Play. Best of all, you can access the full source code of the app from your V-Play installation. You can use this source code in any way you like to build mobile apps or games.


        apps-demo-showcase-ios-2 apps-demo-showcase-ios-3 apps-demo-showcase-ios-4 apps-demo-showcase-ios-5


        apps-demo-showcase-android-2 apps-demo-showcase-android-3 apps-demo-showcase-android-4 apps-demo-showcase-android-5

        Sign-up for V-Play now and check out the source code for free!

        You can launch the Showcase Component App from the V-Play Sample Launcher, Qt Creator or from your installation directory.

        You can also download it free for iOS from the App Store or for Android from the Google Play Store.

        google_play_badge-1 itunes_download_link


        V-Play 2.10.0 includes more improvements to V-Play Game Engine, V-Play Apps and V-Play Plugins than any other recent update.

        V-Play Apps

        V-Play 2.10.0 includes lots of new features and improvements for mobile app development.

        Native Sliders

        You can now build even better UIs with our native looking sliders for iOS and Android. Use the AppSlider or AppRangeSlider controls to select values and ranges with native appearance for iOS and Android.


        AppFlickable Component

        The update includes scrolling and display improvements to the AppFlickable component.

        It now uses a default maximumFlickVelocity of dp(3000) which matches the AppListView flick velocity. It also supports scrolling to the top when the statusbar is clicked on iOS.

        Navigation Styling

        V-Play 2.10.0 includes a number of new styling options for the NavigationBar component. You can now show or hide the NavigationBar drop shadow with the new NavigationStack::navigationBarShadow property.

        You can also show or hide a drop shadow below the NavigationBar on Android with the NavigationStack::navigationBarShadow property. The shadow height is customizable with the Theme.navigationBar.shadowHeight setting.

        As well as that, the PageControl component now allows you to jump to a specific page by directly clicking the indicator.

        More Changes

        For a full list of improvements to V-Play Apps in this update, please check out our change log!

        V-Play Game Engine

        Connect with Facebook

        V-Play now lets you connect your matchmaking service and leaderboards with Facebook, giving users even more social features.

        The VPlayMultiplayerView for matchmaking and VPlayGameNetworkView for leaderboards now shows a button that allows players to connect to Facebook if a VPlayGameNetwork::facebookItem is configured.

        If players connect with Facebook and give access to their friends list, they can directly compare scores with their Facebook friends. They can also challenge them to multiplayer matches without the hassle of manually searching for their friends in the game. The player profile, which includes scores, achievements and friends, is synchronized if a player uses the same account on multiple devices.

        V-Play Multiplayer

        You can enjoy a number of improvements to the V-Play Multiplayer feature when you update to V-Play 2.10.0. These updates make it easier for players to begin games or join in existing games.


        For example, you can now use the VPlayMultiplayer::invitePlayers() or VPlayMultiplayer::uninvitePlayer() methods to add or remove players while the game is already open.

        You can activate or deactivate player slots with the MultiplayerUser::enabled property or VPlayMultiplayer::enablePlayer() and VPlayMultiplayer::disablePlayer() methods. This allows you to make multiplayer game for 2, 3, or more players.

        V-Play 2.10.0 also lets you customize the random join feature with the new properties VPlayMultiplayer::customFilterProperties and VPlayMultiplayer::filterSqlQuery so players only join rooms that match their set filter.

        These advanced matchmaking options should boost user engagement and retention as these new features give players more control over who they interact with in your game.

        Learn more about V-Play Multiplayer here!

        V-Play Plugins

        The AdMob, Chartboost and Flurry plugin have all been updated by this release. All 3 plugins now use the latest platform SDK’s for iOS and Android. You can learn more about this by visiting the plugin documentation page.

        See the V-Play change log for a full list of the improvements this release brings to V-Play!


        V-Play 2.10.0 includes fixes for V-Play Apps, V-Play Game Engine and V-Play Plugins. The most important fixes involve V-Play Apps and resolve the following issues:

        • Fixes a compatibility issue of AppTabBar with Qt 5.8 that broke the rendering of the tab buttons.
        • Solves issue of AlphaVideo not showing on some Android devices and correctly scales the video when the item size changes.
        • Hidden Dialog and InputDialog instances no longer consume the Android back-button after they are closed.

        You can see all the fixes this update brings by checking out our change log here!

        How to Update V-Play

        Test out these new features by following these steps

        Step 1

        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.10.0 as described in the V-Play Update Guide.

        If you haven’t installed V-Play yet, you can do so now with the latest installer from here.

        Step 2

        The V-Play Sample Launcher allows you to quickly test and run all the open-source examples and demo apps & games that come with the V-Play SDK, from a single desktop application.

        sample launcher

        After installing V-Play, you can start the V-Play Sample Launcher from the application shortcut in your V-Play SDK directory.

        Now you can explore all of the new features included in V-Play 2.10.0!

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

        NOTE: Please see the paragraph above on how to successfully update to Qt 5.8 for V-Play. Some additional steps are required!

        More Posts like This

        20 Free & Secure Alternatives to the Parse Push Service


        The 13 Best Qt, QML & V-Play Tutorials and Resources for Beginners

        tutorials capture

        21 Tips That Will Improve Your User Acquisition Strategy

        User Acquisition

        7 Useful Tips That Will Improve Your App Store Optimization

        User Acquisition

        The post Release 2.10.0: New App Showcase, Multiplayer & Multi-Language Improvements, Qt 5.8 appeared first on V-Play Engine.

        Qbs 1.7 released

        We are delighted to announce the release of Qbs 1.7 “Technical Ecstasy”!

        While Qbs 1.7.0 was actually released back in mid-December, we decided to postpone the announcement until after last week’s 1.7.1 patch release in order to get in a few more bug fixes.

        What’s new?

        In addition to lots of bugfixes and smaller improvements, as well as some significant performance enhancements, this release also brings a number of new features. Let’s start with the largest and most interesting:


        Generators are a major new feature in Qbs 1.7 that enables deep integration with your favorite third-party development tools.

        The Generators API is designed to be very generic. It provides a means for developers to create “plugins” that perform arbitrary processing on the build graph. So, far we’ve used this to create several generators which output Xcode* and Visual Studio project files. This allows you to develop your projects in your favorite IDE, while still retaining the full power and expressibility of the Qbs build engine.

        We’ve also received a community contribution that outputs a Clang compilation database file. This allows Clang-based tools to scan the sources exactly like the compiler, independently of the build system. We’re excited to see what other generators the community might come up with.

        To get started with generators, try the qbs generate command on your project. The generators documentation will be available in the manual in a future release.

        Note that the generators features are still very experimental. We will greatly appreciate your feedback in this area.

        the Xcode generator is scheduled for release in Qbs 1.8

        Other new features

        • Group items can now be nested. This allows Groups to be structured more naturally, as a Group’s condition property is logically ANDed with its parent’s. It also makes Groups more useful when placed into dedicated files as the inherited QML-like syntax requires a root element.
        • qrc files can be automatically generated from your project file, obviating the need to manually maintain multiple identical file lists. This functionality is part of the Qt.core module and introduces a couple of new properties which allow you to control how files in your project should be automatically added to a generated qrc file.
        • There is now much more complete documentation on Rule authoring. This has been one of our biggest requests in the documentation area.
        • Stricter type checking for properties in Qbs project files, which should help make certain syntax errors much clearer.
        • Microsoft Visual Studio 2017 support in the C/C++ module.
        • QtScxml support in the Qt modules.
        • Support for building Inno Setup installers.

        One last thing worth mentioning is that the Open Source C++ package manager Conan has added support for Qbs. We believe integrations like this which make it easier to integrate third-party content with your projects are a great ecosystem boon.

        Try It!

        The Open Source version is available on the download page, and you can 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-qbs on, and on the mailing list. The documentation and wiki are also great places to get started.

        Qbs is also available on most major packaging systems (Chocolatey, MacPorts, Homebrew) and updated on each release by the Qbs development team. It can also be installed through the native package management system on a number of Linux distributions including but not limited to Debian, Ubuntu, and Arch Linux.

        Qbs 1.7.1 is also included in Qt Creator 4.2.1, which was released last week.

        The post Qbs 1.7 released appeared first on Qt Blog.

        New QtLabs PDF module

        A couple of years ago during a hackathon, a couple of us wrote a Qt wrapper around PDFium, the open-source PDF rendering engine which is used for viewing PDFs in Chromium.  There have been a few fixes and improvements since then.  Now we (finally) have made this module available under the LGPLv3 license.

        QPdfDocument can render a PDF page to a QImage, and there is QPdfBookmarkModel which can be used for a bookmarks view. There is an example application: a widget-based PDF viewer.

        If you want to try it out, here’s how to get started:

        git clone git://
        cd qtpdf
        git submodule update --init --recursive
        cd examples/pdf/pdfviewer
        ./pdfviewer /path/to/my/file.pdf

        There is some work in progress to add support for PDF in QtQuick, to treat it as an ordinary image format and to add support for multi-page image formats in general, but we don’t have any particular target release date yet.

        The post New QtLabs PDF module appeared first on Qt Blog.

        What’s New in Qt on Apple Platforms

        Note that throughout this blog post, the term “Apple Platforms” will be used to refer to all four Apple operating systems (macOS, iOS, tvOS, and watchOS) as a whole.

        I thought it would be a good time to share some of the highlights of what’s new in Qt on Apple Platforms with the recent release of Qt 5.8.

        New Platforms

        To start off, Qt now has Technology Preview level support for Apple TV and Apple Watch devices beginning in Qt 5.8. This completes our offering to support all four Apple Platforms – macOS, iOS, tvOS, and watchOS.

        tvOS (Apple TV)

        Qt for tvOS is 95% similar to iOS (even the UI framework is also UIKit) and as a result, contains roughly the same feature set and supported modules as iOS, with the notable exception of QtWebEngine.

        The major difference between the two platforms is input handling. iOS has a touch-based model that maps fairly well to a traditional point and click desktop interface from a programming perspective, while tvOS has a focus based model. This means that you don’t have a canvas which can receive input at a particular point (x,y coordinate), but rather an abstract canvas in which you “move” the focus to a particular object. When an object has focus, you can use the Apple TV Remote to trigger an action by clicking its trackpad or pressing the Menu or Play/Pause buttons.

        Qt supports some aspects of the tvOS input model (scrolling and clicking are recognized), but there will be some degree of manual work handling input events in QML to build a tvOS app. Most basic navigation actions on the Apple TV Remote are exposed as keyboard events in Qt, and gesture recognizers can be used for more complex multitouch input. We are still exploring ways to provide mechanisms that make it easier to work with this new input model.

        We’d also like to thank Mike Krus doing the initial work of porting Qt to tvOS, and who is now the platform’s maintainer.

        watchOS (Apple Watch)

        Qt for watchOS is also heavily based on iOS. However, it is not possible to run QML or any other Qt based UI on the watch using public APIs because the primary interface API is WatchKit (as opposed to UIKit). Therefore, Qt can currently only be used for non-UI tasks such as networking, audio, backend graphics processing, etc. If the available watchOS APIs change in the future then we can certainly explore the possibilities at that point.

        I am also the watchOS platform maintainer, so please feel free to send me any questions or feedback.

        Shared Libraries on iOS

        Only static libraries were permitted for most of iOS’s existence, as many iOS developers are no doubt aware. Apple’s App Store requirements prohibited shared libraries even though the underlying operating system supported them since 1.0. Finally, with the release of iOS 8 and Xcode 6 in 2014, shared libraries/frameworks became officially supported by Apple for use in applications submitted to the App Store. Unfortunately, while this feature did not make it in time for the Qt 5.8 release… Qt 5.9 will support them too (also for tvOS and watchOS)!

        To build Qt as shared libraries on iOS, all you need to do is pass the -shared option to configure (and this will be the default in the next release). Note that shared libraries require a deployment target of at least iOS 8.0, which will also be the minimum requirement for Qt 5.9.

        With shared libraries, you can simplify your development workflow by not having to maintain separate code paths for static libraries on iOS and shared libraries on other platforms. Shared libraries also allow you to:

        • When using App Extensions (as both your main application and your extension executables may link to the same copy of the Qt frameworks), reduce memory consumption and reduce disk space consumption on your users’ devices as your app will be smaller
        • Make your code base easier to maintain through strict API boundaries and the benefits of namespacing
        • Speed up linking and thus overall build time

        Because the question will inevitably come up: we do not believe shared libraries will have any practical effect for LGPL users. There are other concerns that come into play with the Apple App Store (namely, DRM) which render the point moot. However, we recommend using shared libraries for the technical reasons outlined above. And as always, seek professional legal advice with regard to software licensing matters.

        Build System Enhancements

        In the past several Qt releases we have also made a number of significant enhancements to the build system on Apple Platforms, including:

        • @rpath in the install names of Qt libraries, providing relocatability out of the box (Qt 5.5)
        • Standalone .dSYM debug symbols (Qt 5.6.1, Qt 5.6.2)
        • Building asset catalogs (Qt 5.6.3 & Qt 5.7.1)
        • Bitcode on iOS which allows Qt applications to take advantage of App Thinning (Qt 5.8)
        • Precompiled headers on iOS, tvOS, and watchOS, reducing build time by up to 30% (Qt 5.8)
        • Combined simulator and device builds, doing away with the confusing separate _simulator libraries on iOS (Qt 5.8)
        • Multi-arch (“universal”) builds on macOS, back from Qt 4.x (coming in Qt 5.9)
        • Automatically embedding Qt frameworks within a Qt app bundle in qmake-generated Xcode projects (coming in Qt 5.9)
        • …and many other smaller bug fixes

        One more thing… we’ve been changing every reference to “Mac OS X” and “OS X” that we can find into “macOS”. 🙂

        The post What’s New in Qt on Apple Platforms appeared first on Qt Blog.

        Qt Visual Studio Tools Insights

        While working on the Qt Visual Studio tools, I had to think about how to locally perform and test the update process for extensions. As already known to most Visual Studio users, the IDE provides a way to setup your own private extension gallery. To do so, one has to open the Visual Studio Tools | Options Dialog and create a new Additional Extension Gallery under Environment | Extensions and Updates.

        My initial try was to simply put the generated VSIX into a folder on the disk and point the URL field to this folder. After looking at the Tools | Extensions and Updates dialog, no update was highlighted for the tools. Because this was not as easy as I had thought, so some configuration file probably needed to be provided. A short search on the Internet led to the following article – there we go, it turned out that the configuration file is based on the Atom feed format.

        Visual Studio uses an extended version of the Atom feed format consisting of two parts, the Header and the Entry. The header needs to be provided only once, while the entry can be repeated multiple times. Lets take a look at the header tags:

        <title> The repository name.
        <id> The unique id of the feed.
        <updated> The date/time when the feed was updated.

        Please note that even though these tags do not seem to be important for the desired functionality, it still makes sense to keep them.

        The more interesting part is the Entry tag that describes the actual package you’re going to share. There seem to be a lot of optional tags as well, so I’m just going to describe the most important one. To force an update of your package, simply put an <Vsix> inside the entry tag. It must contain two other tags:

        <id> The id of your VSIX.
        <version> The version of the VSIX.

        As soon as you increase the version number, even without rebuilding the VSIX, Visual Studio will present you with an update notice of your package. For a more advance description of the tags possible, follow this link. If you are looking for the minimum Atom feed file to start with, you can grab a copy of ours here.

        So now one might ask, why did I write all that stuff? Well, while I was preparing the next Qt Visual Studio Tools release I scratched my head quite a bit on this topic. And just maybe – it might save some other developer’s day while doing a Visual Studio extension release. Last but not least, I am happy to announce the availability of an updated version of the Qt Visual Studio Tools with the following improvements:

        • Bug fixes
        • Making it faster
        • Using the new TextMate language files in Visual Studio 2015 SP3 for QML file and QMake project file syntax highlighting

        The Qt Company has prepared convenient installers for the Qt Visual Studio Tools 2.1 release. You can download it from your Qt Account or from They are also available from the Visual Studio Gallery for Visual Studio 2013 and Visual Studio 2015.

        For any issues you may find with the release, please submit a detailed bug report to (after checking for duplicates). You are also welcome to join the discussions in the Qt Project mailing lists, development forums and to contribute to Qt.

        The post Qt Visual Studio Tools Insights appeared first on Qt Blog.


        Another interesting weeks has passed by. We held our first Gothenburg C++ meetup with a nice turn up. We met at the Pelagicore offices in Gothenburg (thanks for the fika) and decided on a format, the cadence and future topics for the group. If you want a primer in C++ and Qt in the next few months, make sure to join us! All the details are on the gbgcpp meetup page. For those of you not based in Gothenburg, there is a Sweden C++ group based in Stockholm.

        Some other, more work related news: Pelagicore are changing offices in Gothenburg and it will be an Upgrade with a capital U! We’ve signed for a really nice office space just across the street from the opera and less than five minutes from the central train station and the Brunnsparken public transport hub of Gothenburg. And as always – we are looking for developers – hint, hint ;-)

        Finally, do not forget that fosdem starts in a week. I’m going, so I’ll see you in Brussels!

        OpenGL Core Profile Context support in QPainter

        As many of you may know, QPainter has a multi-backend architecture and has two main paint engine implementations under the hood in Qt 5: the raster paint engine and the OpenGL2 paint engine, designed for OpenGL ES 2.0.

        The GL Paint Engine

        While in many ways the raster paint engine can be considered one of Qt’s crown jewels, let’s now talk about the other half: the GL paint engine that is used when opening a QPainter on

        The Problem

        What about modern OpenGL, though?

        That is where the problems started appearing: around Qt 5.0 those who were in need of a core profile context due to doing custom OpenGL rendering that needed this ended up running into roadblocks quite often. Components like Qt Quick were initially unable to function with such contexts due to relying on deprecated/removed functionality (for example, client-side pointers), lacking a vertex array object, and supplying GLSL shaders of a version the support for which is not mandated in such contexts.

        In some cases opting for a compatibility profile was a viable workaround. However, Mac OS X / macOS famously lacks support for this: there the choice has been either OpenGL 2.1 or a 3.2+ core profile context. Attempts to work this around by for instance rendering into textures in one context and then using the texture in another context via resource sharing were often futile too, since some platforms tend to reject resource sharing between contexts of different version/profile.


        Fortunately, during the lifetime of Qt 5 things have improved a lot: first Qt Quick, and then other, less user-facing GL-based components got fixed up to be able to function both with core and compatibility contexts.

        As of Qt 5.8 there is one big exception: the GL paint engine for QPainter.

        The Last Missing Piece

        The good news is, this will soon no longer be the case. Thanks to a contribution started by Krita, see here for some interesting background information, QPainter is becoming able to function in core profile contexts as well. Functionality-wise this will not bring any changes, rendering still happens using the same techniques like before.

        In addition to fixing up the original patch, we also integrated it with our internal QPainter regression testing system called Lancelot. This means that in addition to raster (with various QImage formats) and OpenGL 2, there will also be a run with a core profile context from now on, to ensure the output from QPainter does not regress between Qt releases.

        All in all this means that a snippet like the following is now going to function as expected.

          class Window : public QOpenGLWindow {
            void initializeGL() override {
              QSurfaceFormat fmt;
              fmt.setVersion(4, 5); // or anything >= 3.2
            void paintGL() override {
              QPainter p(this);
              p.fillRect(10, 10, 50, 50, Qt::red);


        Qt 5.9.

        The patch has now been merged to qtbase in the ‘dev’ branch. This will soon branch out to ‘5.9’, which, as the name suggests, will provide the content for Qt 5.9. Those who are in urgent need of this can most likely apply the patch (see QTBUG-33535) on top of an earlier version – the number of conflicts are expected to be low (or even zero).

        That’s all for now, have fun with QPainter in core profile contexts!

        The post OpenGL Core Profile Context support in QPainter appeared first on Qt Blog.

        Un-deprecate your Qt project

        The last post from my colleague Marc Mutz about deprecating Q_FOREACH caused quite an uproar amongst the Qt developers who follow this blog. I personally feel that this was caused fundamentally by a perceived threat: there is a cost associated to porting away a codebase from a well-known construct (Q_FOREACH) to a new and yet-undiscovered […]

        The post Un-deprecate your Qt project appeared first on KDAB.

        Stepanov-Regularity and Partially-Formed Objects vs. C++ Value Types

        In this article, I will take a look at one of the fundamental concepts introduced in Alex Stepanov and Paul McJones’ seminal book “Elements of Programming” (EoP for short) — that of a (Semi-)Regular Type and Partially-Formed State. Using these, I shall try to derive rules for C++ implementations of what are commonly called “value […]

        The post Stepanov-Regularity and Partially-Formed Objects vs. C++ Value Types appeared first on KDAB.

        Connecting your Qt application with Google Services using OAuth 2.0

        With the Qt 5.8 release, we have added QtNetworkAuth as a Technology Preview module. It is focused on helping developers with this auth******** madness. Currently, it supports OAuth1 and OAuth2. In the future, it will feature more authorization methods.

        This post is a first glance of the OAuth2 support in Qt, it covers how to use Google to authorize an application. Your application will be able to show the typical log-in/authorize app screen, just like a web application (NOTE: A browser or a webview is needed):


        The IETF defines OAuth 2.0 as:

        The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

        OAuth authorization is also a requirement to use the Google APIs and access user information stored in Google Services like Gmail, Drive, Youtube, Maps, and others.

        If you are interested in how to create an application using OAuth2, please continue reading.

        Register your new project

        Before start writing code, you need to register a new project in the service provider. This step is necessary because you have to request the client credentials to identify your application. The following steps are based on Google API Console but they are similar to other providers.

        Creating new project

        To start the project registration, access Google API Console, then, press “Create Project”.


        A “New Project” dialog appears. Type the name of your project and click the “Create” button. Now you are ready to manage your new project.


        Your application is registered, the dashboard is updated and you can set different options from this screen.


        Creating the credentials

        You have to get credentials to identify the application. Go to the “Credentials” section in the dashboard and press the “Create credentials” button. You need to choose which type of credentials you need. Choose “OAuth client ID”.


        In the next screen, you can configure a “consent screen” with your Email address, product name, homepage, product logo, … Fill it with your data and press the “Save” button.

        Go back to the previous “Create client ID” screen to choose the “Application type”. Different options are available here; you need to choose “Web application”. Give it a name.


        Under “Restrictions” there is an important field: the “Authorized redirect URIs”.

        If the user chooses to allow your application to manage his data. The application has to receive an “access token” to be used during authenticated calls. The “access token” can be received in several ways, but the most common way is to receive a call to your web server with the “access token”. In web applications, a server path to handle the notification is enough. A desktop application need to fake it using a local browser.

        Add a URI accessible by your Internet browser including the port if you are using a different one than 80. When the application is running, a basic HTTP server will receive information from the browser.

        Most of the times you need to use a URI like: “http://localhost:8080/cb”.

        NOTE: The path “/cb” is mandatory in the current QOAuthHttpServerReplyHandler implementation.

        NOTE: You can configure different URIs. In this example, a single URI is assumed.

        End the process by pressing the “Create” button and you will see a new credential in the list of credentials with an “Edit”, “Delete” and “Download” buttons at the right. Click the download button and… Finally, you get a JSON file ready to parse!


        In the screenshot above you can see some new URIs and the client_id and the client_secret. There is no need to use the JSON file, you can hardcode this information directly in your application.

        Writing the Google API Wrapper code

        I will omit the part of defining the class and show the relevant code.

        In your code create a QOAuth2AuthorizationCodeFlow object:

        auto google = new QOAuth2AuthorizationCodeFlow;

        Configure the scope you need to access from the application. The scope is the desired permissions the application needs. It can be a single string or a list of strings separated by a character defined by the provider. (Google uses the space character as separator).

        NOTE: The scopes are different depending on the provider. To get a list of scopes supported by Google APIs click here.

        Let’s use the scope to access the user email:


        Connect the authorizeWithBrowser signal to the QDesktopServices::openUrl function to open an external browser to complete the authorization.

        connect(google, &QOAuth2AuthorizationCodeFlow::authorizeWithBrowser,

        Parse the downloaded JSON to get the settings and information needed. document is an object of type QJsonDocument with the file loaded.

        const auto object = document.object();
        const auto settingsObject = object["web"].toObject();
        const QUrl authUri(settingsObject["auth_uri"].toString());
        const auto clientId = settingsObject["client_id"].toString();
        const QUrl tokenUri(settingsObject["token_uri"].toString());
        const auto clientSecret(settingsObject["client_secret"].toString());
        const auto redirectUris = settingsObject["redirect_uris"].toArray();
        const QUrl redirectUri(redirectUris[0].toString()); // Get the first URI
        const auto port = static_cast<quint16>(redirectUri.port()); // Get the port


        After parsing the file configure the google object.


        Create and assign a QOAuthHttpServerReplyHandler as the reply handler of the QOAuth2AuthorizationCodeFlow object. A reply handler is an object that handles the answers from the server and gets the tokens as the result of the authorization process.

        auto replyHandler = new QOAuthHttpServerReplyHandler(port, this);

        The grant function will start the authorization process.


        If everything was OK, you should receive a QOAuth2AuthorizationCodeFlow::granted signal and start sending authorized requests.

        You can try sending a request using

        auto reply = google->get(QUrl(""));


        It will give you a QNetworkReply and when QNetworkReply::finished is emited you will be able to read the data.

        To be continued…

        The post Connecting your Qt application with Google Services using OAuth 2.0 appeared first on Qt Blog.

        Cutelyst 1.3.0 released

        Only 21 days after the last stable release and some huge progress was made.

        The first big addition is a contribution by Matthias Fehring, which adds a validator module, allowing you to validate user input fast and easy. A multitude of user input types is available, such as email, IP address, JSON, date and many more. With a syntax that can be used in multiple threads and avoid recreating the parsing rules:

        static Validator v({ new ValidatorRequired(QStringLiteral("username") });
        if (v.validate(c,Validator::FillStashOnError)) { ... }

        Then I wanted to replace uWSGI on my server and use cutelyst-wsgi, but although performance benchmark shows that NGINX still talks faster to cutelyst-wsgi using proxy_pass (HTTP), I wanted to have FastCGI or uwsgi protocol support.

        Evaluating FastCGI vs uwsgi was somehow easy, FastCGI is widely supported and due a bad design decision uwsgi protocol has no concept of keep alive. So the client talks to NGINX with keep alive but NGINX when talking to your app keeps closing the connection, and this makes a huge difference, even if you are using UNIX domain sockets.

        uWSGI has served us well, but performance and flexible wise it's not the right choice anymore, uWSGI when in async mode has a fixed number of workers, which makes forking take longer and user a lot of more RAM memory, it also doesn't support keep alive on any protocol, it will in 2.1 release (that nobody knows when will be release) support keep alive in HTTP but I still fail to see how that would scale with fixed resources.

        Here are some numbers when benchmarking with a single worker on my laptop:

        uWSGI 30k req/s (FastCGI protocol doesn't support keep conn)
        uWSGI 32k req/s (uwsgi protocol that also doesn't support keeping connections)
        cutelyst-wsgi 24k req/s (FastCGI keep_conn off)
        cutelyst-wsgi 40k req/s (FastCGI keep_conn on)
        cutelyst-wsgi 42k req/s (HTTP proxy_pass with keep conn on)

        As you can see the uwsgi protocol is faster than FastCGI so if you still need uWSGI, use uwsgi protocol, but there's a clear win in using cutelyst-wsgi.

        UNIX sockets weren't supported in cutelyst-wsgi and are now supported with a HACK, yeah sadly QLocalServer doesn't expose the socket description, plus another few stuff which are waiting for response on their bug reports (maybe I find time to write and ask for review), so I inspect the children() until a QSocketNotifier is found and there I get it. Works great but might break in future Qt releases I know, at least it won't crash.

        With UNIX sockets command line options like --uid, --gid, --chown-socket, --socket-access, as well as systemd notify integration.

        All of this made me review some code and realize a bad decision I've made which was to store headers in lower case, since uWSGI and FastCGI protocol bring them in upper case form I was wasting time converting them, if the request comes by HTTP protocol it's case insensitive so we have to normalize anyway. This behavior is also used by frameworks like Django and the change brought a good performance boost, this will only break your code if you use request headers in your Grantlee templates (which is uncommon and we still have few users). When normalizing headers in Headers class it was causing QString to detach also giving us a performance penalty, it will still detach if you don't try to access/set the headers in the stored form (ie CONTENT_TYPE).

        These changes made for a boost from 60k req/s to 80k req/s on my machine.

        But we are not done, Matthias Fehring also found a security issue, I dunno when but some change I did break the code that returned an invalid user which was used to check if the authentication was successful, leading a valid username to authenticate even when the logs showed that password didn't match, with his patch I added unit tests to make sure this never breaks again.

        And to finish today I wrote unit test to test PBKDF2 according to RFC 6070, and while there I noticed that the code could be faster, before my changes all tests were taking 44s, and now take 22s twice as fast is important since it's a CPU bound code that needs to be fast to authenticate users without wasting your CPU cycles.

        Get it!

        Oh and while the FreeNode #cutelyst IRC channel is still empty I created a Cutelyst on Google groups:!forum/cutelyst

        Have fun!

        Qt 5.8 released

        I am happy to announce that Qt 5.8 has been released today and is available for download from Qt 5.8 does of course come with Qt Creator 4.2.1 and an update to Qt for Device Creation. Qt 5.8 is a rather large release, containing quite a large set of new functionality. Let’s have a look at some of them:

        Qt Lite

        One of the main themes of Qt 5.8 has been to make Qt more flexible and easier to adopt to your use case, targeted especially at our embedded users. Qt Lite has been the codename of the project under which we did those changes.

        Our goal has been to make it easier to configure Qt to exactly your needs and leave out features that you don’t need in your project. This brings major savings in the size of the compiled Qt libraries and thus your application.

        Implementing support for this put us on a longer journey, where we rewrote most parts of the system that was being used to configure Qt. The new system cleans up a system that had grown over the last 15 years, and that also lead to many inconsistencies on how Qt was being configured on different host platforms.

        As a result, we now have one unified system to configure the different parts of Qt. In addition to giving our users a lot more flexibility in configuring Qt, it will also ease our burden in supporting all the different ways Qt can be configured and used.

        Using the new system allows you to create a Qt build tailored to exactly your use case. You can leave out all the features in Qt that you don’t need, saving ROM and RAM when deploying to your embedded device. To give you an idea of the size savings possible, the image below shows the size of the required Qt stack to run a small QML application:

        Size of sample app using Qt 5.6 and a lite configuration of Qt 5.8

        As you can see, the new configuration system allows for significant reductions in size and savings of more than 60% in binary size compared to Qt 5.6.

        Qt Wayland Compositor

        The Qt Wayland Compositor API that we included as a Technology Preview in Qt 5.7 is now fully supported in Qt 5.8. The module makes it very easy to create your own Wayland Compositor.

        Qt Wayland Compositor make it very easy to implement your own custom home screen and application manager. This allows the creation of powerful and more complex embedded systems where you have multiple applications that have their own user interfaces. Qt Wayland Compositor supports handling multiple screens in an easy and transparent way. It comes with both QML and C++ APIs.

        For more details, have a look at the API documentation and examples, as well as this blog post, which also features a tutorial.

        Communication and Networking

        Qt Serialbus has now graduated to be fully supported in Qt 5.8. It allows you to use Qt APIs for device bus communications and protocols. While the API is rather generic, this version includes implementations for CAN and Modbus.

        Qt Network and Web Sockets gained full support for TLS PSK cyphersuites. Qt Network now supports configurable Diffie-Hellman parameters and HTTP/2 in QNetworkAccessManager.

        Qt Bluetooth gains BTLE Peripheral support on macOS and iOS as well as BTLE Central support on WinRT.

        Qt 5.8 also adds a new Qt Network Authorization module as a Technology Preview, currently supporting the OAuth 1 and 2 authentication schemes.

        Qt QML and Quick

        Quite a few things have happened in Qt QML and Qt Quick. The QML engine has gained support for caching binary representations of QML and JS files on disk, reducing startup time and memory consumption of the engine. The commercial only Qt Quick compiler is still supported in 5.8, but we are planning to merge it with the new caching infrastructure in the future, leading to a better performing and more tightly integrated solution.

        The Qt Quick scene graph has undergone a larger refactoring, making it less dependent on OpenGL. This allowed us to add an experimental Direct3D 12 backend for Qt Quick, and does enable the creation of other backends e.g. based on the Vulkan graphics APIs.

        In addition, the scene graph now supports partial updates to the screen if only a small area of the scenography changed. This brings some larger performance improvements to the Qt Quick 2D renderer.

        We also used the changes to the scene graph as an opportunity to fold the functionality of the Qt Quick 2D renderer into Qt Quick directly. This implies that the Qt Quick 2D renderer does not exist as a standalone module in Qt 5.8 anymore.

        Larger changes have also been done under the hood with respect to Mouse and Touch event handling, unifying them internally in a new QQuickPointerEvent class. This lays the foundation for future improvements to mouse and touch event handling, but doesn’t affect code using Qt Quick yet.

        The Qt Quick Controls 2 have also gained a couple of new types such as dialogs, rounded buttons and tool separators. The Material and Universal styles have gained some new effects and support for a ‘system’ theme.

        Qt Webengine

        As always the Chromium version used by Qt Webengine has been updated, this time to Chromium 53. One long outstanding feature added in Qt 5.8 is the ability to print web pages. Many smaller new features have been added, amongst them a new QML API to define custom dialogs, tootips and context menus, and support for view-source: and some chrome: schemes.

        Qt SCXML

        Qt SCXML is now fully supported in Qt 5.8. The module makes is trivial to integrate SCXML based state machines into Qt. It builds directly onto the Qt Statemachine Framework, and extends it with with both a SCXML to C++ compiler and a runtime that allows loading SCXML based state machines.

        Together with the Qt SCXML module, Qt Creator 4.2 gained support for editing state charts.

        New Technology Previews

        Also in Qt 5.8, we have new functionality that we chose to introduce as a Technology Preview.

        Qt now compiles for both Apple’s tvOS and watchOS. While most of the functionality that we support on iOS should also work on tvOS, watchOS support is limited to the non-graphical functionality in Qt.

        Qt Speech has been added as a new module adding support to text to speech functionality.

        Other improvements

        After the initial release of Qt 3D with Qt 5.7, the focus for 5.8 has been on maturing the module. A large amount of bug fixes and performance improvements have been made for the module.

        Qt Charts has gained a Candlestick chart type and we have made the QOpenGLTextureBlitter API in Qt Gui public.

        Our embedded platforms supported by Qt for Device Creation have gained better support for multi-screen systems when using the eglfs QPA plugin and support for 90/180 degree rotated screens.

        Finally, many changes happened to our code base to make better use of the new features offered by C++11 and with that clean up and modernize our code base.

        Thanks to the Qt Community

        Qt 5.8 adds a lot of new functionality and improvements. Some of them would not have been possible without the help of the great community of companies and people that contribute to Qt by contributing new functionality, bug fixes, documentation, examples or bug reports. Thank you!

        You can read more about the release and watch our launch video here, get Qt 5.8 from your Qt Account or I hope you’ll like and enjoy the new release!

        The post Qt 5.8 released appeared first on Qt Blog.

        Qt SCXML and State Chart Support in Qt Creator

        Qt has provided support for state machine based development since introduction of Qt State Machine Framework in Qt 4.6. With the new functionality introduced in Qt 5.8 and Qt Creator 4.2 state machine based development is now easier than ever before.

        Qt 5.8 introduces fully supported Qt SCXML module that makes it easy to integrate SCXML based state machines into Qt. Previously SCXML has been imported to Qt from external tools, which is still possible. Now Qt Creator 4.2 introduces a new experimental visual state chart editor that allows creation and modification of state charts directly with Qt Creator IDE. Together with the new editor and other improvements in Qt Creator, state machine based development can be done completely within Qt Creator.

        Here is a short screen cast that shows these new features in action. For demonstration purposes, the simple state machine driven example application with Qt Quick user interface Traffic Light is being recreated from scratch.

        Note that the the editor is still experimental with Qt Creator 4.2 and the plugin is not loaded by default. Turn it on in Help > About Plugins (Qt Creator > About Plugins on macOS) to try it.

        The post Qt SCXML and State Chart Support in Qt Creator appeared first on Qt Blog.

        Creating devices with multiple UI processes using Wayland

        In the early days of devices with a user interface, there was a single process that ran the user interface component. This was a nice way to separate out the user interface from the logic controlling the device and to ensure responsiveness for the end user. As hardware costs fell while simultaneously becoming more capable, we found more things for our devices to do. The user interface needed to be able to handle many more things, including asynchronous events and presenting information coming in from multiple places. Think of the transition from simple phones doing SMS, to feature phones and now smartphones which are more powerful than PCs of a decade ago. To run the whole UI of a smartphone in a single process would be considered madness today. Why not use similar techniques for building complex device user interfaces?

        Devices with a multi-process user interface have several benefits:

        • Stability and robustness: By splitting your application into multiple functional units you maximize the stability of each application and if one application crashes it will not affect the other applications.
        • Efficient development: Separate teams can work on each application with lower risk of breaking something that the other team is working on.
        • Security: You can run applications with reduced privileges meaning that they can’t influence or access each other.
        • 3rd party application development: You can easily enable your device to be opened up to 3rd party app development. You can even mix and match applications from different UI toolkits.


        Why Wayland?

        multi-screen-demoHaving made the decision to have multiple process for the user interface display, the next technical problem to solve is getting the outputs of each process onto the display. Historically the approach has been to use X and write your own window manager.

        The modern approach is to use Wayland, which is a simpler replacement for X.

        • It’s easy to develop and maintain
        • It’s a modern approach to window management designed with today’s graphical hardware in mind
        • The protocol is easily extendable
        • Wayland is the new industry standard for window management—it’s a common protocol that can be used by everyone, and is extended by everyone

        With Wayland, the compositor is responsible for arranging and displaying each client’s content or output on the screen.

        Wayland in Qt

        Earlier versions of Qt provide the Qt Window System (QWS), which shares some of the design goals of Wayland. However, QWS only supports Qt-based clients and its architecture is not suited to modern OpenGL-based hardware. With Qt 5 we therefore started working on Wayland. Running Qt applications as Wayland clients has been officially supported since Qt 5.4.

        Qt Wayland Compositor API

        With Qt 5.8 we have released the Qt Wayland Compositor API, which allows you to create your own Wayland compositor. We give you all the tools you need to create a compositor in a simple way. You can easily define the UI and UX of your compositor with the power and simplicity of QML. If you still need or want to use C++, that’s also possible. There are also many other benefits of using the Qt Wayland Compositor API:

        • Creating multi-screen devices is simple
        • High abstraction level API means less lines of code to test and debug
        • Support for easily writing your own Wayland extensions—Allowing easy communication between clients and the compositor. E.g. you could write a protocol extension for telling clients to switch to night mode.
        • Built-in support for several shell extensions including XDG shell, WL Shell and IVI application allowing to connect to clients using any of these extensions

        I hope this has piqued some interest in creating multi-process devices with the Qt Wayland Compositor API. To see for yourself how easily it can be done, check out the 10-minute tutorial below.

        To get started, download Qt 5.8

        The post Creating devices with multiple UI processes using Wayland appeared first on Qt Blog.

        Qt Creator 4.2.1 released

        We are happy to announce the release of Qt Creator 4.2.1. This is a pure bugfix release, and takes care of various important bugs.

        Several properties of run configurations were only initialized when entering the Projects
        mode, leading to various issues when running QMake projects, and projects that run custom executables, which have now been fixed.

        In 4.2 we fixed iOS Simulator support for Xcode 8. Unfortunately there still were
        problems, especially when running on iOS 10 simulator devices.
        We adapted the way we start applications on the simulator, and this should now reliably
        work again.

        There have been a range of smaller bug fixes as well, please have a look at our change log
        for more details.

        Get Qt Creator 4.2.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.2.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, and on the Qt Creator mailing list.

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

        Inside QImage (with a touch of Qt Quick and OpenGL)

        QImage is the most common container for image data in Qt applications.

        Getting a QImage that contains the pixel data of an image loaded from a file is fairly self-explanatory:

        QImage img;

        This can then be used with QPainter, can be passed to widgets, and can also be utilized in Qt Quick scenes via custom image provider implementations. (although the latter would obviously be a massive overkill for image data coming from a file since that’s what the Image element provides out of the box anyway).

        So far so good. Now, what if the image data is coming from somewhere else? For example a custom drawing made via QPainter, or an image that comes from some external engine, like a camera, scanner or computer vision framework?

        The answer lies in some of the 9 constructors. The interesting ones for our purposes are the following:

        QImage(int width, int height, Format format);
        QImage(uchar *data, int width, int height, Format format, ...);
        QImage(uchar *data, int width, int height, int bytesPerLine, Format format, …);
        QImage(const uchar *data, int width, int height, ...);
        QImage(const uchar *data, int width, int height, int bytesPerLine, Format format, …);

        Let’s now take a look at some of the common use cases and how these constructors serve the specific needs of each case.

        Case #1: Image data owned by the QImage

        The common case when generating images on-the-fly, is using QPainter and its raster paint engine to draw into a QImage:

        QImage img(640, 480, QImage::Format_ARGB32_Premultiplied);
        QPainter p(&img);
        p.fillRect(10, 10, 50, 50, Qt::red);

        Here the underlying image data is allocated and owned by img itself.

        When it comes to the format for images that will be passed to Qt Quick, the basic recommendations (as of Qt 5.8) are the following:

        • In general, the first choice should be Format_ARGB32_Premultiplied. This is good because it is one of the preferred, fast formats for the raster paint engine, which QPainter uses under the hood when targeting a QImage, and the premultiplied format fits Qt Quick well since the scenegraph renderer and its materials rely on premultiplied alpha for blending. When creating textures for our image, the default, OpenGL-based Qt Quick scenegraph will avoid any potentially expensive QImage format conversion for ARGB32_Premultiplied images.
        • When there is no need for an alpha channel at all, due to our image being completely opaque, Format_RGB32 is a good alternative. This comes with the same benefit: no format conversion when creating an OpenGL scenegraph texture from such a QImage.

        Other formats will lead to a convertToFormat() call at some point, which is not necessarily ideal. It is better to get the format right from the start.

        It is worth noting that in order to get a proper no-conversion-by-Qt-on-CPU path, the OpenGL implementation must support GL_EXT_bgra, GL_EXT_texture_format_BGRA8888, or some of the vendor-specific variants. This can be relevant on older, OpenGL ES 2.0 only systems where BGRA support is not mandated by the GLES spec. In the absence of these (A)RGB32 image data will internally need either an additional swizzle step (this is what Quick and pretty much all old Qt 4 code does) or a conversion to a byte ordered QImage format (preferred by some of the newer code in QtGui and elsewhere), because the (A)RGB32 formats are not byte ordered.

        What are byte ordered however are the Format_RGB(A|X)8888[_Premultiplied] formats introduced in Qt 5.2. These are nice because when read as bytes, the order is R, G, B, A on both little and big endian systems, meaning the image data can be passed to a glTex(Sub)Image2D call using a GL_RGBA format with a GL_UNSIGNED_BYTE data type as-is.

        • When targeting older OpenGL ES 2.0 systems is a must, custom OpenGL rendering code (for example, inside a QOpenGLWindow, QOpenGLWidget, QQuickFramebufferObject, etc.) can benefit from using QImages with a byte ordered format like Format_RGBA8888, simply because there is less code to write. (no manual swizzling or extra QImage format conversion is needed when BGRA support is missing)
        • Some of QtGui’s OpenGL helpers that may be used by such code, most notably QOpenGLTexture, also prefer Format_RGBA8888 when working with QImage, and will kick off a conversion for other formats.

        Therefore, the older default recommendation of using Format_ARGB32_Premultiplied or Format_RGB32 is not necessarily valid always. In the context of Qt Quick however, sticking with these formats will typically still be the right choice.

        Case #2: Wrapping external, read-only image data

        Now, what if the image data is readily available from an external engine? The common solution here is to use the QImage constructor taking a const uchar pointer.

        void *data = ...
        QImage wrapper(static_cast<const uchar *>(data), 640, 480, QImage::Format_RGB32);
        // 'wrapper' does not own the data.
        // 'data' must stay valid until 'wrapper' is alive.

        There are no memory allocations and copies made here. It is up to the application to ensure the width, height, format, and optionally the bytes per line reflect the raw image data received from the other framework or engine.

        Like many other container classes in Qt, QImage is using implicit sharing. This is handy because this way a QImage can be passed or returned by value without having to worry avoid expensive copies of the actual image data.

        Instances created from a const uchar * are special in the sense that any attempt to modify the QImage (via a non-const function) detaches (makes a copy) regardless of the reference count. Hence attempts to modify to original, external data are futile:

        const uchar *data = ...
        QImage wrapper(data, ...);
        wrapper.setPixelColor(5, 5, Qt::green);
        // 'wrapper' is not a wrapper anymore,
        // it made a full copy and got detached

        Note that while this is all nice in theory, and the zero-copy approach is great in some cases, in practice making copies of the data is often unavoidable due to the need for format conversions in order to match the needs of the various frameworks. For example when interfacing with OpenCV, the code (taken from here) to convert a CV_8UC4 image into a QImage could look like this:

        QImage mat8ToImage(const cv::Mat &mat)
            switch (mat.type()) {
            case CV_8UC4: {
                QImage wrapper(static_cast<const uchar *>(, mat.cols, mat.rows, int(mat.step), QImage::Format_RGB32);
                return wrapper.rgbSwapped();

        (NB! It does not matter if we use the const or non-const pointer variant of the constructor here. A copy will be made either way due to the semantics of rgbSwapped())

        Case #3: Wrapping and modifying external image data

        What about the constructor taking an uchar pointer? As the non-const argument suggests, this allows modifying the external, non-owned data via a wrapping QImage, without making copies of the image data. Modification often means opening a QPainter on the QImage:

        void *data = ...
        QImage img(static_cast<uchar *>(data), 640, 480, QImage::Format_RGB32);
        QPainter p(&img);
        p.fillRect(10, 10, 50, 50, Qt::red);
        ... // 'data' must stay valid as long as 'img' is alive

        Here we paint a red rectangle on top of the existing content.

        This is made possible by a perhaps at first confusing feature of QImage: with non-owned, non-read-only data modification attempts will not detach when the reference count is 1 (i.e. the image data is not shared between multiple QImage instances).

        Compare this behavior with something like QString::fromRawData() which explicitly says: Any attempts to modify the QString or copies of it will cause it to create a deep copy of the data, ensuring that the raw data isn’t modified.

        There a container associated with external data always makes a copy, and does not support modifying the external data. With QImage this is not acceptable, since the ability to change the pixels of an image from an arbitrary source without making a copy is a must have.

        See this little example project for a demonstration of painting into a manually allocated image. It also demonstrates one potential issue one may run into when getting started with such a QImage:

        void drawStuff_Wrong(QImage image)
            QPainter p(&image); // oops
            p.fillRect(10, 10, 50, 50, Qt::red);
        QImage wrapper(data, 640, 480, QImage::Format_RGB32);

        This is clearly broken. The red rectangle will not appear in the original image pointed to by ‘data’. Due to passing to the function by value the image gets its refcount increased to 2, and so the modification attempt when opening the QPainter has to detach with a full copy. The solution here is to pass by pointer or reference. (or yet better do not pass at all; QImage instances referencing external data should ideally be isolated as much as possible, in order to avoid issues like the one above)

        Accessing the image data

        And last but not least, let’s talk about accessing the bytes of a QImage.

        For read access, something like QImage::pixel() clearly does not scale when having to examining a larger part of the image. Instead, use constBits() or constScanLine().

        QImage img(640, 480, QImage::Format_ARGB32_Premultiplied);
        const uchar *p = img.constBits();
        // 'p' is valid as long as 'img' is alive

        Read-write access is done via bits() and scanLine(). These exist in both const and non-const version. The const version are in effect same as constBits() and constScanLine(). In practice it is strongly recommended to use constBits() and constScanLine() whenever read-only access is desired, in order to avoid accidentally invoking the non-const bits() or scanLine(), and making expensive and totally unnecessary copies of the image data.

        QImage img1(640, 480, QImage::Format_RGB32);
        QImage img2 = img1;
        const uchar *p = img1.bits();
        // ouch! that's the non-const bits(). img1 detaches.
        // we only wanted read access and yet wasted time with a copy.

        Due to img1 not being const this should have been:

        QImage img1(640, 480, QImage::Format_RGB32);
        QImage img2 = img1;
        const uchar *p = img1.constBits();
        // no copy, img1 and img2 still share the same data

        The non-const versions detach when multiple instances share the same data or when the image wraps read-only, external data (via the const uchar * constructor).

        That is all for now. Hope this clears up some of the uncertainties that may arise when looking at the QImage API for the first time, and helps to avoid some of the pitfalls when working with external image data. Happy hacking with QImage!

        The post Inside QImage (with a touch of Qt Quick and OpenGL) appeared first on Qt Blog.

        Qt Speech (Text to Speech) is here

        I’m happy that with Qt 5.8.0 we’ll have Qt Speech added as a new tech preview module. It took a while to get it in shape since the poor thing sometimes did not get the attention it deserved. We had trouble with some Android builds before that backend received proper care. Luckily there’s always the great Qt community to help out.
        Example application show Qt Text to Speech
        What’s in the package? Text to speech, that’s about it. The module is rather small, it abstracts away different platform backends to let you (or rather your apps) say smart things. In the screen shot you see that speech dispatcher on Linux does not care much about gender, that’s platform dependent and we do our best to give you access to the different voices and information about them.

        Making the common things as simple as possible with a clear API is the prime goal. How simple?
        You can optionally select an engine (some platforms have several). Set a locale and voice, but by default, just create an instance of QTextToSpeech and connect a signal or two. Then call say().

        m_speech = new QTextToSpeech(this);
        connect(m_speech, &QTextToSpeech::stateChanged,
                this, &Window::stateChanged);
        m_speech->say("Hello World!");

        And that’s about it. Give it a spin. It’s a tech preview, so if there’s feedback that the API is incomplete or we got it all wrong, let us know so we can fix it ASAP. Here’s the documentation.

        I’d like to thank everyone who contributed, Maurice and Richard at The Qt Company, but especially our community contributors who were there from day one. Jeremy Whiting for general improvements and encouragement along the way (I bet he almost gave up on this project). Samuel Nevala and Michael Dippold did implement most of the Android backend, finally getting things into shape. Thanks!

        You may wonder about future development of Qt Speech. There are some small issues in the Text to Speech part (saving voices and the current state in general should be easier, for example). When it comes to speech recognition, I realized that that’s a big project, which deserves proper focus. There are many exciting things that can and should be done, currently I feel we need proper research of all the different options. From a simple command/picker mode to dictation, from offline options and native backends to the various cloud APIs. I’d rather end up with a good API that can wrap all of these in a way that makes sense (so probably a bunch of classes, but I don’t have a clear picture in my mind yet) than rushing it. I hope we’ll get there eventually, because it’s certainly an area that is important and becoming more and more relevant, but I assume it will take some time until we have completed the offering.

        The post Qt Speech (Text to Speech) is here appeared first on Qt Blog.

        How to shoot yourself in the foot using only a scene graph (neat optimization trick inside)

        by Eskil Abrahamsen Blomfeldt (Qt Blog)

        I am trying to get into the habit of blogging more often, also about topics that may not warrant a white paper worth of text, but that may be interesting to some of you. For those of you who don’t know me, I am the maintainer of the text and font code in Qt, and recently I came across a curious customer case where the optimization mechanisms in the Qt Quick scene graph ended up doing more harm than good. I thought I would share the case with you, along with the work-around I ended up giving to the customer.

        Consider an application of considerable complexity: Lots of dials and lists and buttons and functionality crammed into a single screen. On this screen there are obviously also labels. Thousands of static labels, just to describe what all the complex dials and buttons do. All the labels share the same font and style.

        Narrowing the example down to just the labels, here is an illustration:

        import QtQuick 2.5
        import QtQuick.Window 2.2
        Window {
            id: window
            visible: true
            title: qsTr("Hello World")
            visibility: Window.Maximized
            Flow {
                anchors.fill: parent
                Repeater {
                    model: 1000
                    Text {
                        text: "Hello World"

        Now, the way the scene graph was designed, it will make an effort to bundle together as much of a single primitive as possible, in order to minimize the number of draw calls and state changes needed to render a scene (batching). Next, it will try to keep as much as possible of the data in graphics memory between frames to avoid unnecessary uploads (retention). So if you have a set of text labels that never change and are always visible, using the same font, essentially Qt will merge them into a single list of vertices, upload this to the GPU in one go and retain the data in graphics memory for the duration of the application.

        Example screenshot

        Artist’s impression of a complex Qt application

        We can see this in action by setting the environment variable QSG_RENDERER_DEBUG=render before running the application above. In the first frame, all the data will be uploaded, but if we cause the scene graph to re-render (for instance by changing the window size), we see output like this:

        Renderer::render() QSGAbstractRenderer(0x2a392d67640) "rebuild: none"
         -> Opaque: 0 nodes in 0 batches...
         -> Alpha: 1000 nodes in 1 batches...
         - 0x2a39351fcb0 [retained] [noclip] [ alpha] [  merged]  Nodes: 1000  Vertices: 40000  Indices: 60000  root: 0x0 opacity: 1
         -> times: build: 0, prepare(opaque/alpha): 0/0, sorting: 0, upload(opaque/alpha): 0/0, render: 0

        From this we can read the following: The application has one batch of alpha-blended material, containing 1000 nodes. The full 40000 vertices are retained in graphics memory between the frames, so we can repaint everything without uploading the data again.

        So far so good.

        But then this happens: Someone adds another label to our UI, somewhere in the depths of this complex graph of buttons, dials and labels. This label is not static, however, but shows a millisecond counter which is updated for every single frame.

        While the scene graph does the correct and performant thing for most common use cases, the introduction of this single counter item in our scene breaks the preconditions. Since the counter label will be batched together with the static text, we will invalidate all the geometry in the graph every time it is changed.

        To see what I mean, lets change our example and run it again.

        import QtQuick 2.5
        import QtQuick.Window 2.2
        Window {
            id: window
            visible: true
            title: qsTr("Hello World")
            visibility: Window.Maximized
            property int number: 0
            Flow {
                anchors.fill: parent
                Repeater {
                    model: 1000
                    Text {
                        text: index === 500 ? number : "Hello World"
            NumberAnimation on number {
                duration: 200
                from: 0
                to: 9
                loops: Animation.Infinite

        The example looks the same, except that the 501st Text item is now a counter, looping from 0 to 9 continuously. For every render pass, we now get output like this:

        Renderer::render() QSGAbstractRenderer(0x1e671914460) "rebuild: full"
         -> Opaque: 0 nodes in 0 batches...
         -> Alpha: 1000 nodes in 1 batches...
         - 0x1e672111f60 [  upload] [noclip] [ alpha] [  merged]  Nodes: 1000  Vertices: 39964  Indices: 59946  root: 0x0 opacity: 1
         -> times: build: 0, prepare(opaque/alpha): 0/0, sorting: 0, upload(opaque/alpha): 0/1, render: 0

        As we can see, we still have a single batch with 1000 nodes, but the data is not retained, causing us to upload almost 40000 vertices per frame. In a more complex application, this may also invalidate other parts of the graph. We could even end up redoing everything for every frame if we are especially unlucky.

        So, presented with this case and after analyzing what was actually going on, my first goal was to find a work-around for the customer. I needed to come up with a way to separate out the counter label into its own batch, without changing how anything looked on screen. There may be more ways of doing this, but what I ended up suggesting to the customer was to set clip to true for all the counter labels. Giving the counters a clip node parent in the graph will force them out of the main batch, and the updates will thus be isolated to the clipped part of the scene graph.

        import QtQuick 2.5
        import QtQuick.Window 2.2
        Window {
            id: window
            visible: true
            title: qsTr("Hello World")
            visibility: Window.Maximized
            property int number: 0
            Flow {
                anchors.fill: parent
                Repeater {
                    model: 1000
                    Text {
                        text: index === 500 ? number : "Hello World"
                        clip: index === 500
            NumberAnimation on number {
                duration: 200
                from: 0
                to: 9
                loops: Animation.Infinite

        Still the same code, except that the clip property of the 501st Text item is now set to true. If we run this updated form of the application with the same debug output, we get the following:

        Renderer::render() QSGAbstractRenderer(0x143890afa10) "rebuild: partial"
         -> Opaque: 0 nodes in 0 batches...
         -> Alpha: 1000 nodes in 3 batches...
         - 0x143898ee6d0 [retained] [noclip] [ alpha] [  merged]  Nodes:  500  Vertices: 20000  Indices: 30000  root: 0x0 opacity: 1
         - 0x143898ec7e0 [  upload] [  clip] [ alpha] [  merged]  Nodes:    1  Vertices:     4  Indices:     6  root: 0x14389a3a840 opacity: 1
         - 0x143898edb90 [retained] [noclip] [ alpha] [  merged]  Nodes:  499  Vertices: 19960  Indices: 29940  root: 0x0 opacity: 1
         -> times: build: 0, prepare(opaque/alpha): 0/0, sorting: 0, upload(opaque/alpha): 0/0, render: 0

        As you can see from the output, the text is now divided into three batches instead of one. The first and last are retained between frames, causing the full upload for each frame to be an insignificant 4 vertices. Since the clip rect contains the bounding rect of the text, we will not actually clip away any pixels, so the application will still look the same as before.

        So all is well that ends well: The customer was happy with the solution and their performance problems were fixed.

        Also, I gained some ideas on how we can improve the Qt Quick API to make it easier for users to avoid these problems in the future. Since we want performance to be stable from the first frame, I don’t think there is any way to get around the need for users to manually identify which parts of the graph should be isolated from the rest, but I would like to have a more obvious way of doing so than clipping. My current idea is to introduce a set of optimization flags to the Qt Quick Text element, one of which is Text.StaticText, sister to the QStaticText class we have for QPainter-based applications.

        In the first iteration of this, the only effect of the flag will be to ensure that no label marked as StaticText will ever be batched together with non-static text. But down the road, maybe there are other optimizations we can do when we know a text label never (or rarely) changes. And this is just one of a few optimization APIs I want to add to Qt Quick Text in the near future, so stay tuned! 🙂

        The post How to shoot yourself in the foot using only a scene graph (neat optimization trick inside) appeared first on Qt Blog.

        Qt Was Really Everywhere at CES2017

        CES 2017 was full of autonomous driving, artificial intelligence and virtual assistants. It was great to see the momentum in the industry towards the future. While all of the innovative, future oriented technologies were present, there was also room for more modern technologies such as plastic mobile phone covers. Somewhere in between today and tomorrow were digital cockpits with a variety of implementations.

        Qt based technologies were demoed everywhere by OEMs, Tiers1, silicon vendors and various solution providers. Some partners had made it very easy to find Qt – both Harman and Greenhills for example had hard printed Qt logos on their booth infrastructure, HERE and Pelagicore had Qt logos on the software, while some partners (when asked) said that Qt was the technology driving their demos. Of course, there were also product demos that were on display where one just needed to have some inside information to know that the demo was using Qt.

        Qt was presented in many different roles: UI used to demonstrate underlying hardware technology, developer platform for generic applications or a holistic digital cockpit solution for traditional cars, as well as driver’s/passengers’ UI for autonomous cars. Most interestingly there was not a single competitor’s technology covering all of these use cases. Based on my biased, one-man market study I could claim Qt was the most versatile automotive technology at CES.

        Using Qt in hardware demoes is easy to understand. Qt enables fast UI creation if the partner wants to demo for example performance of the underlying platform. In addition, Qt was used to visualize the sensor data either as for pure demo or real use case in autonomous driving scenario.

        As Qt is used in over 70 different industries the applications are easy to find. Most interestingly big service / software brands have started to use Qt in OEM specific application development. Good example being Skype for Business by Volvo.

        The trend from IVIs and instrument clusters to digital cockpits was very clear across the Tier1s and OEMs. The more futuristic the cockpit you saw the more difficult it was to split the functionality. Based on several discussions with OEMs, Tier1s and other solution providers the future is all about one software platform on one hardware system. It was not only The Qt Company who had selected Qt for comprehensive digital cockpit solution, the whole industry is looking at Qt.

        In short, Qt is everywhere at CES2017 was true.


        The post Qt Was Really Everywhere at CES2017 appeared first on Qt Blog.

        “Unboxing” the Android Things Developer Preview

        Android Things is Google’s answer to creating an environment for IoT devices. Take a slimmed down Android build, add some sensor-specific APIs, and provide it on a number of powerful pre-integrated micro-boards and you have a ready-made platform for building a host of upcoming IoT devices. Android Things can take advantage of many existing Android […]

        The post “Unboxing” the Android Things Developer Preview appeared first on KDAB.