OpenGL

Introducing the Qt Quick 2D Renderer

Published Thursday January 22nd, 2015 | by

When Qt Quick 2 was introduced with the release of Qt 5.0, it came with a minimum requirement of either OpenGL 2.0 or OpenGL ES 2.0.  For desktop and mobile platforms this is usually not an issue, and when it is for example on Windows, it is now fairly easy to use an OpenGL software rasteriser as a fallback.  If however your target is an embedded device without a GPU capable of OpenGL ES 2.0, then software rasterisation of OpenGL is an unwise option.  It is typical that the embedded devices without a GPU have less CPU resources available as well, so the overhead introduced by the software rasterisation of OpenGL leads to unacceptable performance for even the most simple content.  Also many of the performance optimisations gained by using OpenGL for rendering Qt Quick 2 scenes are negated by software rasterisation.

So as a solution to our Professional and Enterprise customers we are now providing an alternative scene graph renderer called the Qt Quick 2D Renderer.  The Qt Quick 2D Renderer works by rendering the Qt Quick scene graph using Qt’s raster paint engine instead of using OpenGL. Read more …

10 Comments


Posted in Embedded, OpenGL, Qt Quick 2

Qt Weekly #23: Qt 5.5 enhancements for Linux graphics and input stacks

Published Tuesday January 20th, 2015 | by

The upcoming Qt 5.5 has received a number of improvements when it comes to running without a windowing system on Linux. While these target mainly Embedded Linux devices, they are also interesting for those wishing to run Qt applications on their desktop machines directly on the Linux console without X11 or Wayland.

We will now take a closer look at the new approach to supporting kernel mode setting and the direct rendering manager, as well as the recently introduced libinput support.

Read more …

6 Comments


Posted in Embedded, Graphics, OpenGL, QPA

Multi-process embedded systems with Qt for Device Creation and Wayland

Published Tuesday December 9th, 2014 | by

With the Qt 5.4 update for Qt for Device Creation it is now possible – on certain embedded systems – to run Qt applications on top of a Wayland compositor by relying only on the provided reference images without any additional modifications. While the stable and supported approach remains eglfs, the lightweight platform plugin that allows running fullscreen Qt applications on top of EGL and fbdev with the best possible performance, those who do not require any of the enhanced tooling but need to have multiple GUI applications running on the same screen can start experimenting with a Wayland-based system already today.

In this post we will take a look how this can be done on i.MX6 based systems, like for example the Sabre SD and BD-SL-i.MX6 boards.

Read more …

3 Comments


Posted in Embedded, Graphics, OpenGL

Qt Weekly #21: Dynamic OpenGL implementation loading in Qt 5.4

Published Thursday November 27th, 2014 | by

In Qt 5.4 there is a new configure option on Windows: -opengl dynamic. This, in addition to -opengl desktop and -opengl es2, changes the OpenGL implementation (and implicitly the window system interface API) that Qt is built against. However, unlike the previously existing flags, dynamic is something different. Enabling it ensures that neither the Qt libraries nor the applications link directly to an OpenGL implementation, meaning that neither opengl32.lib nor libEGL.lib + libGLESv2.lib are passed to the linker. Instead, Qt will, upon application startup, choose the implementation to load.

Starting with the Qt 5.4 release candidate the previously ANGLE-only pre-built packages are changed to be dynamic builds. It is therefore time to take a closer look at this feature.

Read more …

15 Comments


Posted in Graphics, OpenGL, Qt Quick, Windows

Qt Weekly #20: Completing the offering: QOpenGLWindow and QRasterWindow

Published Thursday November 20th, 2014 | by

Together with the introduction of QOpenGLWidget, Qt 5.4 adds two more classes: QOpenGLWindow and QRasterWindow. Let us now look at the list of native window classes and OpenGL container widgets. The list may look long and confusing at first glance, but it is all quite logical so everything will fall into place quickly:

  • QWindow: Represents a native window in the windowing system. The fundamental window class in Qt 5. Every top-level window, be it widget or Quick based, will have a QWindow under the hood. Can also be used directly, without widgets or Quick, both for OpenGL and software rendered graphics. Has no dependencies to the traditional QWidget stack.
  • QRasterWindow: Convenience wrapper over QWindow for software rendered graphics.
  • QOpenGLWindow: Convenience wrapper over QWindow for OpenGL graphics. Optionally backed by a framebuffer object, but the default behavior (and thus performance) is equivalent to QWindow.
  • QOpenGLWidget: The modern replacement for Qt 4’s QGLWidget. A widget for showing OpenGL rendered content. Can be used like any other QWidget. Backed by a framebuffer object.
  • QQuickWindow: A QWindow subclass for displaying a Qt Quick 2 (QML) scene.
  • QQuickView: Convenience wrapper for QQuickWindow for easy setup of scenes loaded from QML files.
  • QQuickWidget: The equivalent of QQuickView in the QWidget world. Like QOpenGLWidget, it allows embedding a Qt Quick 2 scene into a traditional widget-based user interface. Backed by a framebuffer object.

For completeness sake, it is worth noting two additional APIs:

  • QQuickRenderControl: Allows rendering Qt Quick 2 scenes into framebuffer objects, instead of targeting an on-screen QQuickWindow.
  • QWidget::createWindowContainer(): In Qt 5.1 & 5.2 the only way to embed Qt Quick 2 content (or in fact any QWindow) into a widget-based UI was via this function. With the introduction of QQuickWidget and QOpenGLWidget this approach should be avoided as much as possible. Its usage should be restricted to cases where it is absolutely neccessary to have a real native window embedded into the widget-based interface and the framebuffer object-based, more robust alternatives are not acceptable, or where it is known in advance that the user interface layout is such that the embedded window will not cause issues (for example because the embedded window does not care about input, is not part of complex layouts that often get resized, etc.).

We will now take a look at no. 2 & 3, the QWindow convenience wrappers.

Read more …

17 Comments


Posted in Graphics, OpenGL, QPA, Qt

Qt Weekly #19: QOpenGLWidget

Published Wednesday September 10th, 2014 | by

After Qt 5.3’s introduction of QQuickWidget, Qt 5.4 adds QOpenGLWidget, the long-awaited replacement for the legacy QGLWidget. This widget retains the familiar initializeGL/resizeGL/paintGL API, while enabling full interoperability with other widgets in complex user interfaces.

Internally QOpenGLWidget is built on the same technology as QQuickWidget. Unlike QGLWidget, it is not a native window and will not turn any siblings or ancestors into native either. This avoids stacking, clipping, focus and performance issues and is expected to behave identically across all supported platforms.

Read more …

16 Comments


Posted in Graphics, OpenGL, Qt

Bringing the magic of Qt to Windows Runtime

Published Tuesday March 25th, 2014 | by

We’ve been hard at work on the Windows Runtime (WinRT) port and it’s about time we share a bit with all of you. For Qt 5.3, we’re releasing the WinRT port as Beta quality, with most of the Qt Essentials modules in functional form (including QML & Quick). We also have preliminary tooling support, so you can get started on WinRT as quickly as you would on any other supported Qt platform.

An API for modern devices

As a reminder, Windows Runtime is a new API largely tied to Windows Store Apps, or applications which run within the Modern UI environment. It has C++ bindings (among other languages), and can be used on Windows 8, Windows Phone 8, and Windows RT – running the gamut from budget smartphones to high-end PCs. That’s a lot of devices.

One of the most important things for us (and many of you) has been getting Qt Quick working smoothly on the platform. As you might guess, there are some limitations to getting such a stack working here. For one, the memory APIs which are commonly used by just-in-time (JIT) compilers (such as in QtQml’s virtual machine engine) are restricted and cannot be used by apps in the Windows Store (this is, of course, for platform security reasons; the same restriction is in place on iOS). Fortunately, the V4 virtual machine which premiered in Qt 5.2 has solved this problem swimmingly, allowing WinRT to utilize the interpreted codepath for these types of operations (albeit at the cost of some less optimal code execution speed).
Read more …

18 Comments


Posted in cross-platform, integration, OpenGL, QPA, Qt Quick 2, Windows, WinRT

Qt Data Visualization 1.0 Beta

Published Thursday January 30th, 2014 | by

I’m happy to announce that we have now released the Qt Enterprise Data Visualization add-on 1.0 beta. The implementation has gone through quite many changes after we released the Technology Preview. We have been doing a lot of re-factoring both in the API and in the internals of the implementation so that we lay as solid foundation to further development as possible.

Datavisualization_Beta_Bars Datavisualization_beta_scatter2

Changes include:

  • Support for multiple series (surface not yet supported)
  • User modifiable themes
  • Improved input handling
  • Rotation of items in Scatter and Bar graphs
  • QML antialiasing support added
  • Added missing support for multiple graphs in same window
  • New examples
  • iOS support added

Read more …

Comments Off


Posted in Charts, Declarative UI, Graphics, OpenGL

New Scene Graph Renderer

Published Monday September 2nd, 2013 | by

Few phrases are more misused in software, whispered in social channels, promised over the negotiating table or shouted out loud in blogs, as the words “The next release will make everything better!”

So… I won’t say that.

But…

Qt 5.2 introduces a new renderer to the Qt Quick Scene Graph.

When we set out to do the scene graph some three years ago, one of my visions was that we would be able to really take advantage of OpenGL and have game-like performance. The renderer we have in Qt 5.0 went a long way towards that goal. For opaque content, we sort based on state and render content front-to-back to minimize GPU overdraw. In the playground/scenegraph repository, we have a different renderer which batches similar primitives together to reduce the number of draw calls (which implicitly also reduces state changes).

The new renderer in Qt 5.2 combines both of these techniques and also tries to identify non-changing parts of the scene so they can be retained on the GPU. Qt 5.2 also adds the texture atlas support which was previously located in the playground/scenegraph’s customcontext. This greatly helps batching of textured content. I think that with Qt 5.2, we are now pretty close to that goal.

A new doc article explaining the renderer in more detail has been added for the more curious, though a deep understanding of the renderer is not needed to write well-performing applications. However, I suspect many people will still find it interesting.

http://doc-snapshot.qt-project.org/qt5-stable/qtquick-visualcanvas-scenegraph-renderer.html

 

There are still a lot of other ideas that could be employed for those who want to have a stab at it. If you have ideas, ping “sletta” on IRC or clone and start coding.

Now some numbers:

Three of the benchmarks are available here: https://github.com/qtproject/playground-scenegraph/tree/master/benchmarks

  • Extreme Table contains a large static table with some animated content on top. It shows the benefit of the GPU retention.
  • List Bench shows a number of simultaneously scrolling lists with an icon, alternating background color, and two texts per cell.
  • Flying Icons contains over 3000 images which are being animated with a unique animation per item.

I also included the front-page of the Qt Quick Controls gallery example and Samegame. Samegame is played in “Zen” mode while clicking to the rhythm of “Where Eagles Dare” by Iron Maiden. (I know… very scientific)

The number of OpenGL draw calls and amount of traffic is measured using apitrace, an awesome tool if you’re debugging OpenGL. As can be seen by the green numbers, we’ve managed to cut down the number of glXxx calls quite a bit, especially for the cases where we have plenty of re-occurrence, meaning lists, tables and grids.

The amount of traffic per frame is also significantly improved. The best examples are the “ExtremeTable” and “ListBench” which are sampled at a frame where no new delegates were being added or removed. I’m quite happy that the “ListBench” comes out as a zero-transfer frame. There is of course some traffic, the draw calls themselves and a couple of uniforms; but no vertex data and no texture data, which is what the tool measures. “FlyingIcons” changes the entire scene every frame so nothing can be retained, so minimal difference is expected. Controls Gallery is mostly static, but has an animated progress bar which needs a new texture every frame. This is the majority of the 20+kb transfer. Samegame comes out pretty high, primarily because of its extensive use of particle systems. A lesson learned is that if you are on a tiny memory bus, limit your particles.

These are theoretical numbers, but they give a good idea that the new renderer is on the right track. Let us look at numbers from running on hardware. I’ve created tables out of the cases where the new renderer had the most impact. The full table of numbers is at the very bottom.

Note, these benchmarks are run without the new V4-based QML engine. This is because the V4 engine also affects the results and I wanted to focus on rendering only.

The rendering time is measured with vsync enabled, but excluding the swap. So when we see that the MacBook spends 16ms rendering, it is actually being throttled while we are issuing OpenGL commands. When Iooked at this in Mac OS X’s Instruments, I saw that the driver was spending a lot of time in synchronous waiting, aka we have stalling in the pipeline. With the Qt 5.2 rendering, the synchronous waiting while drawing is gone. This is good news, as lists and list-like content is quite common in UIs.

In both the MacBook with Integrated chip and on the Nexus, the new renderer drastically reduces the time spent issuing OpenGL commands. It should also be said that the only reason the render times for the “ExtremeTable” did not go all the way to 0 is because of https://bugreports.qt-project.org/browse/QTBUG-32997

“FlyingIcons” high CPU load is mostly primarily due to it running 3000+ animations in parallel, but as we can see from the time spent in the renderer, that there is still significant improvement.

Here are the rest of the numbers:

So this matches up pretty well with the theoretical results at the beginning. For reoccurring content, such as lists and grids, Qt 5.2 is quite an improvement over Qt 5.1. For those use cases we didn’t radically improve, we at least didn’t make them any worse.

Enjoy!

40 Comments


Posted in Graphics, OpenGL, Qt Quick 2.0

Introducing QWidget::createWindowContainer()

Published Tuesday February 19th, 2013 | by

Qt 5 introduced a new set of OpenGL classes in Qt Gui and a new rendering pipeline for Qt Quick with the scenegraph. As awesome as these are, they were based on the newly introduced QWindow, making it very hard to use them in existing applications.

To remedy this problem, Qt 5.1 introduces the function QWidget::createWindowContainer(). A function that creates a QWidget wrapper for an existing QWindow, allowing it to live inside a QWidget-based application. Using QQuickView or QOpenGLContext together with widgets is now possible.

How to use

QQuickView *view = new QQuickView();
...

QWidget *container = QWidget::createWindowContainer(view);
container->setMinimumSize(...);
container->setMaximumSize(...);
container->setFocusPolicy(Qt::TabFocus);

widgetLayout->addWidget(container);

How it works

The window container works by forcing the use of native child widgets inside the widgets hierarchy and will reparent the window in the windowing system. After that, the container will manage the window’s geometry and visibility. The rendering of the window happens directly in the window without any interference from the widgets, resulting in optimal performance.

As can be seen from the code-snippet above, the container can also receive focus.

Embedding the “Other Way”

This feature covers the use case where an application wants to either port an existing view to either Qt Quick or the new OpenGL classes in Qt Gui. What about the use case where an application’s mainview is written with widgets, say QGraphicsView, and the application wants to keep this and rewrite the surrounding UI with Qt Quick? Well, this is doable by keeping the main application QWidget-based and making each of the big UI blocks a QQuickView embedded in its own container.

Enjoy!

22 Comments


Posted in OpenGL, Qt, Qt Quick 2.0

  1. Pages:
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5