tHeBloG

Qt 5.2 Beta was released on yesterday, whey! As many of us know already, Qt 5.2 will be the first Qt version with an official Android support. Qt 5.2 will also contain quite a big changes on the UI side, with the new V4 JavaScript engine and the Scene Graph renderer. So how well does this beta run existing Qt Quick 2.0 applications on Android? We have made numerous UI demos in the past so I decided to install Qt 5.2 beta into Nexus 7 (2013) and put it into test! Here's video: Overall I'm impressed by the quality. Qt Creator is able to setup Android projects with ease, things work and performance is very good. What more could one ask? I encourage everyone to test this beta and report bugs so we'll get things close to perfection before 5.2.0 release, due by the end of November. Keep calm and hack on!

After the QUItIndicator trilogy which introduced idea, design and performance of a specific Qt5 QML component there's room for more, right?! Something like this: This time we have a dynamic QML component for showing the remaining power of your mobile device battery. As a recap, with "Dynamic QML component" I mean someting which utilizes not only basic QML animation properties (position, opacity, scale etc.) but also new Qt5 features (shaders, particles, scenegraph powa!) to appear "more dynamic". Maybe it's just me, but I would love to see UIs really utilizing modern GPUs... and accelerating this progress is one of the reasons why I code these examples and blog about them. Another reason being to rule-the-world, obviously ;-P Instead of explaining design & features of QUItBattery component I'll let this video to do that: If you want to use this liquid battery component in your UI: Download the sources from here , copy QUItBatteryCompone...

(This is part III, please check also parts I and II ) Even with a small component like this, there are plenty of possibilities to improve (or sink) the performance. To make sure that our indicators perform as expected, we'll test them on Nokia N9 and and on Raspberry Pi. These both devices are relatively low-end by current standards. N9 contains 1GHz Cortex-A8 CPU which is still quite beefy, but GPU (SGX530) on the other hand is getting old and unable to handle more complicated fragment shaders. For RPi these are just the opposite: CPU is slowish 700MHz ARM11 while the GPU (VideoCore IV) is more performant than N9 SGX530. Because of these qualities (and because both support Qt5, naturally) this duo is excellent for our performance ensurement. So here's a short video showing how our indicators perform on Nokia N9 and on RaspberryPi: Performs pretty OK on both, right? ProgressIndicator stress test isn't smooth on RPi, which indicates that its CPU can't handle...

(This is part II, for the introduction see part I ) The main points of this indicators exercise are to promote Qt5 QML+GLSL approach for building dynamic UI components (part I) and to give performance tips (part III, coming!). But here in the middle, we talk also a bit about design considerations behind these indicators. After all, who cares if your component performs well if it doesn't also look good and fulfil its functionality. Here's set of design-related notes about QUItIndicators which we wanted to achieve: The design language should be relatively neutral. Indicators like these may be used in many places, in applications and games, so they should not be too characteristic. And circles are pretty universal, so circles it is. The amount of circles in BusyIndicator is 11, by design. Reason behind this is that ProgressIndicator has one missing from top to mark start/end position, meaning 10 circles. This is optimal for percentages math e.g. when user sees 4 circles hig...

Few months ago I wrote a normal mapping series with part I and part II . That was a good experience, so series it is again! This time about implementing dynamic QML components, with an example case being busy&progress indicators. We'll call these specific ones QUItIndicators. Let's start with obligatory video which demonstrates these components, BusyIndicator and ProgressIndicator, with few examples: Traditionally indicators like these would be implemented as an animated GIF or a sprite. Cons of that approach are zero customization and memory consumption: 2s animation of 256x256px 32-bit color indicator at 60fps would mean 2*60*256*256*4 = 31.5Mb memory consumption. That's quite a bit for just one indicator, so usually frames are animated slower than 60fps which makes animation less smooth. Alternative way to implement animated indicator would be using imperative drawing API (QPainter, Cairo, Skia etc.). Drawing freely to a canvas gives a lot of possibilities,...