Thursday, November 9, 2017

Qt 5.10 QML Shape testing

When implementing component into QtQuick UI which needs something more than rectangles, images and texts, pure declarative QML hasn't been enough. Popular choices to use for items with some sort of vector drawing are QML Canvas, QQuickPaintedItem or QNanoPainter.

But with Qt 5.10 there will be supports for new Shape element with paths that contain lines, quads, arcs etc. so I decided to install Qt 5.10 beta3 and implement all tests of "qnanopainter_vs_qpainter_demo" with also QML + Shape elements. (This kinda makes it "qnanopainter_vs_qpainter_vs_qmlshape_demo" but not renaming now). So here is in all glory the same UI implemented with QNanoPainter (left), QQuickPaintedItem (center), and QML+Shape (right):


Hard to spot the differences right? If only there would be a way to prove this, some way to x-ray into these UIs... like QSG_VISUALIZE=overdraw to visualize what Qt Quick Scene Graph Renderer sees?


Here you can see that scene graph sees QNanoPainter and QQuickPaintedItem as just big unknown rectangles, while QML+Shape it sees into as that is composed of native scene graph nodes. But proof is in the pudding as they say, what looks the same doesn't perform the same. Here's a video showing all 3 running with two different Android devices:



As different rendering components can be enabled/disabled and settings changed, this demo is quite nice for doing performance comparisons of both exact drawing methods or combining all methods. But those will have to wait for another blog post and for non-beta Qt 5.10 to get fair results. In the mean time, feel free to pull latest sources from github, test yourself and provide patches or comments!

Wednesday, October 25, 2017

FitGraph NG UI prototype

About a month ago I started exercising more, mostly jogging, weights and soccer (with kids). Target is to be in superb shape when 2018 starts, and I'm already feeling stronger & more energetic during the day so looking good!

Anyway, this blog post is somewhat related to that. There's plenty of health-related apps and gadgets available these days and in the past I used some time pondering what would be a perfect activity tracking app for my needs. Now I decided to revive this earlier concept as 'FitGraph NG' while porting it to use QNanoPainter and polishing some parts.

As usual, let's start with a video demonstrating the actual application:


There would of course be more views available, this being just the 'activity timeline' part, but it would already cover many of my initial wishes:
  • Showing the whole day as a graph, data or textually depending on needs.
  • Automatic annotation of activities, type, duration and related activity data. And importantly, being able to select each activity to cover only data during that.
  • See how well you have reached your 'moves' goal which would come from all your activities.
  • Also collect other notes, goals, concerns etc. during the day.
I could write quite a long presentation about this, explain why things are where they are, how interactions are thought out, pinpoint small (but important!) details etc. But don't want to, you can watch the video few times and ponder about those yourself if you wish.

Some more information about the implementation side:
  • Implemented with Qt, so cross-platform on Android, iOS etc. Application logic C++ and UI naturally QML with few shaders.
  • Graphs are painted with single QNanoPainter item for efficiency. Graph animations are driven from QML side for easy tuning.
  • Data is managed with SQLite and fetched into QAbstractListModel. There's configurable QCache to reduce SQL queries. Data in this prototype is generated dummy, but basically allows "unlimited" scrolling of days.
  • Performance was important target, some tricks and optimizations were required to get application working fluidly at 60fps also on lower end Android devices. 
Thoughts welcome and thanks for reading!

Monday, October 23, 2017

Unity testing

Couple weeks ago I decided to study a bit about Unity as I haven't worked with it before. So implemented a simple "Rock Rolling in Terrain" game prototype as a case study, looking like this:


By coincidence Marko also just made a nice blog post related to Unity, and thanks to standard assets his terrain even looks quite similar to mine so not going to repeat similar notes. But all in all my initial feeling is that Unity seems quite productive environment and wouldn't mind implementing some bigger project with it to get deeper.

Sunday, March 12, 2017

QNanoPainter with Qt 5.8 (and QSGRenderNode)

QNanoPainter recently gained initial support for QSGRenderNode which is a new public class available starting from Qt 5.8. What this means is that instead of rendering through FBO using QQuickFramebufferObject so, OpenGL drawing is done directly into Qt Quick Scene Graph. And as a QQuickItem somewhere in the middle of scene, not just underlay/overlay for the scene which was already possible before Qt 5.8 using beforeRendering & afterRendering.

Below is a video running QNanoPainter tester app on MacBook Pro with 16 unique QQuickItems using QSGRenderNode mode:



So should you enable QNANO_USE_RENDERNODE with your custom QNanoPainter items?

  • There is a potential performance gain for not rendering through FBO. Especially if your UI contains many custom items and/or you resize items, QSGRenderNode may give more gains as FBO resizing can be costly.
  • However, based on my testing with few different Android devices the performance difference seems pretty small, just few percentages. Maybe with some less performant embedded platforms which are bad with FBOs there is a bigger difference.
  • With QQuickFramebufferObject, rendering is always clipped to FBO size, so item clip true/false property doesn’t have any effect. With QSGRenderNode such clipping doesn’t automatically happen, instead each item can freely paint anywhere outside its rect. Whether this is pros or cons is up to your use case, but good to note anyway.
  • With QSGRenderNode, standard QQuickItem features (position, rotation, clipping, scaling etc.) need to be implemented customly. QNanoPainter doesn’t (yet) fully support clipping of QML item tree so if you have several clip regions and/or rotate these items, clipping doesn’t necessarily behave as expected when using QNANO_USE_RENDERNODE.
  • When your item doesn’t need to be repainted, just re-rendered, it’s more performant to render the FBO. So if your items don’t change often it might be better not to enable QNANO_USE_RENDERNODE.

So with all above said, QNANO_USE_RENDERNODE is not currently enabled by default even when building with Qt 5.8. But that might change somewhere in future if gains seem worth it. For now please upgrade your QNanoPainter library and test how it works for you.

Sunday, January 24, 2016

QNanoPainter - a brief update

QNanoPainter has been now publicly available for about a month and during this time has seen some nice improvements.

Gunnar first added Windows support, then worked on reducing QNanoQuickItemPainter creation time and memory consumption with multiple items. Niels and Jean-Michaƫl did some performance testing on Linux & NVIDIA shield, results discussed in issue 6. Examples Gallery was restructured and now contains 3 examples: QNanoPainter Features, Mouse Event Boxes, and Freehand Painting.

Here’s what they look on Nexus 6:


(best viewed in HD)


So, if you are working with Qt5 and have a need for custom QQuickItems, I warmly recommend checking out QNanoPainter. Thanks to everyone involved!

Friday, December 25, 2015

QNanoPainter Available!

About 2.5 months ago I introduced QNanoPainter project for implementing custom QQuickItems. We’ve been really busy (and continue to be so) with other things but took now the time to push QNanoPainter publicly available for wider audience in here: https://github.com/QUItCoding/qnanopainter


It’s not ready (as software never is), but already quite capable for serious kicking of tires. Just clone it, build with Qt Creator / qmake and run the provided examples. And when you want to try implementing own items, straightforward instructions to get started are available at front-page README.

If you dig it and want to assist in improving QNanoPainter, here are few ideas for patches:

  • We have tested QNanoPainter on OS X, Linux, Android and iOS. What’s missing at least is making it work on Windows (with dynamic OpenGL build of Qt).
  • Documentation with QDoc has been started but it’s not complete. There are plenty of ”TODO: Write more documentation here” comments in classes and documentation could overall be improved and styled.
  • Current NanoVG version used is from fork https://github.com/ytsedan/nanovg at bfbac9a35e, with some additions. Custom additions are marked with ”// ### Added”. Some reasons to go with this fork for now instead of upstream are discussed in https://github.com/memononen/nanovg/issues/216. What should be done is to update NanoVG to some latest version, apply additions and test properly. Maybe own NanoVG fork with additions should be maintained?
  • Instead of stb_truetype and stb_image code could be ported to use Qt for images and texts. I think at least text rendering would require private Qt headers and additions in Qt side, so may not be that straightforward.
  • Bugfixes!

We received some good comments already and hopefully now more & patches when sources are publicly available. I’ll write some more blog posts later, but now.. Clone!

Sunday, October 4, 2015

Introducing QNanoPainter

Qt World Summit is just about to start! I’m not participating this time, but wanted to contribute one-more-thing to discuss in UI groups at the heart of Berlin ;)

During the past about six months we at QUIt Coding have had a side-side-project called QNanoPainter. This library is designed for implementing custom QQuickItems into Qt5 scene graph. Currently if you want to implement custom Qt Quick item, options are at least:

  • QQuickItem: Offers best performance due to Qt5 scene graph integration. But QSG* classes are relatively low-level with vertices, indices & materials. Painting more complicated things requires quite an expert and even then productivity is not very high.
  • QQuickFramebufferObject: This is a good option if you want to draw with OpenGL into QQuickItem. But as we all know, OpenGL is also quite low-level API so no productivity wins here.
  • QQuickPaintedItem: This means painting with good old QPainter C++ API. Weakness of QPainter with modern graphics accelerated hardware is that you either get good antialiased quality (QImage rendering target) or fast OpenGL painting (FBO rendering target) but not both. Qt raster engine is very good CPU backend but GPUs are ruling the world these days. And QPainter OpenGL backend doesn’t itself support antialiasing, it requires multisampling with GL_EXT_framebuffer_multisample and GL_EXT_framebuffer_blit extensions as explained here by Laszlo. In case you set FBO target and antialiasing on with hardware that doesn’t support these (e.g. Nexus6 and iPhone6), target with automatically switch back to QImage & raster with performance dipping on most devices.
  • QtQuick Canvas: Canvas item is implemented on top of QPainter so it has mostly same cons and pros as QQuickPaintedItem. HTML5 Canvas API is nice and popular but there is some overhead from (QPainter) API mismatch and JavaScript especially if more drawing data needs to be exported from C++ side.
  • QML ShaderEffect: As you can’t really mess with the mesh, this approach suits for simple cases where fragment shader is enough. But we are now thinking a bit more complicated items where this option isn’t enough or at least becomes complicated and slow.


So isn’t these options enough, still need something else? Yes, I think so.

QNanoPainter is our novel approach for trying to offer performance, productivity and rendering quality all in one. In a nutshell QNanoPainter is:

  • Excellent NanoVG OpenGL library as a drawing backend with some patches for performance & features.
  • QNanoPainter C++ API on top of NanoVG (which is written with C). This API is mixture of QPainter and HTML5 canvas APIs. Offers vector drawing, images and text rendering with classes such as QNanoPainter, QNanoFont, QNanoImagePattern, QNanoLinearGradient etc.
  • QNanoQuickItem to implement items into Qt Quick scene graph. Basically it’s like QQuickPaintedItem, but instead of QPainter offers QNanoPainter API for drawing.
  • Some examples like QNanoPainter vs. QPainter demo and Gallery, more to come.


One thing we have tried is to implement demo with same painting result using QPainter (QQuickPaintedItem) and QNanoPainter (QNanoQuickItem). Performance comparison is always tricky (and it’s not just about performance), but with comparable antialiased painting we are seeing 3-10 times better performance with QNanoPainter depending on hardware, content, item sizes etc. Here’s a short video showing this demo running on iPhone6 and Nexus6 with all tests on (iPhone6 in fact painting everything twice to get more juice out of it):


(best viewed in HD)


QNanoPainter is still work-in-progress and not ready for releasing. But we would like to hear what others think: Which (of the above) options do you use for custom QML items? Have you had issues finding suitable option for some use-cases? If yes, what features have you missed and would like to have?

Just comment here, tweet with #qnanopainter or email to info{at}quitcoding.com, thanks!