I saw this tweet today on a QML performance debate and wanted to reply, but the Twitter 160 char limit wasn’t quite enough, so here goes.
@mece66 pointed out that setting a big cache buffer eliminates scroll problems. I’d say this is only half true. Even if you set a big cache buffer (the thing that caches delegates when they go outside of the list area so that they don’t have to be constructed again) for the ListView the first scroll through the items will still suck, because the delegates will still be generated on the go when they appear for the first time. Subsequent scrolls up and down will of course be remedied by the use of cache buffer. This is how it used to work at least on Qt 4.7.3.
The way I’ve been working around this is wrapping a Column + Repeater combo in Flickable, which produces ListView like behavior with a few restrictions. The difference in perceived scrolling performance comes from the fact that Repeater will construct all the items when the model is set and not during scrolling which solves the problem of the first scroll that sucks. It’s actually quite easy to switch from ListView to the FCR combo as you can plug in your existing ListView delegate to the Repeater without any changes. Header and footer items (if you have them) can be put around the Repeater inside the Column.
Then the restrictions. Some ListView features like sections, key navigation, highlights, etc. naturally go out of the door (some of these could be hacked on top of all though). The model length * delegate complexity can’t be too high, or the UI will be frozen for a moment when all of the delegates are created. In my experience things are ok up to ~500ms in the case of say receiving stuff from the network and then updating the list. Depends a lot on the UI and use case of course. Also a high number of items (amount of delegates * items in them) seems to slow things down when scrolling. I suspect this is due to the fact that QDeclarativeView disables the BSP-tree of QGraphicsView and the items outside the drawable area go all the way to the paint engine (worst case all the way to OpenGL, OpenVG guts where they’re finally clipped). If someone can confirm this, please do so.
All this is actually a pet peeve of mine in QML. Things are made so simple and elegant that the developer looses too much of low level control. Real world isn’t simple and elegant. Real world is messy, complex and full of corner cases. I would love to be able to instruct the QML elements more on their lower level behavior. For example instruct the image loading mechanism on the order you want your asynchronous images to be loaded, which range of ListView items I want to create right away after setting the model, etc.
All of these could of course be fixed if a group of motivated people would sit down and kick off a project that produced a new set of QML elements better suited for the particular tastes of developers. I seriously considered writing a replacement for the Image element and the image loading, but gave up on the thought after two-eleven when things started looking less hot in the Qt mobile segment. Hmm…
A while ago I got a N950 (the MeeGo/Harmattan developer device) from Nokia (thank you very much). I’ve been playing around with it a bit and preparing for porting a Symbian/QML app. Porting the actual QML application is easy. Just adjust the layouts here and there, produce higher resolution variants of bitmap graphics, etc. The nastier part is finding out how to do some things that are not provided by Qt. In my case I would’ve wanted to use the native “camera roll” component that the native apps use for picking an image taken with the device camera. Continue reading
I haven’t feeling like writing much since two-eleven for obvious reasons, but my friend Tuukka (he’s the goatee (pull it and say hi from me) guy giving the course you might be attending when you’re reading this) gave me a proverbial kick in the butt. To get going again I’ll start with something easy, but which is a true gem. This is so simple that it truly hurts.
Like so many others I bought a Xbox Kinect a couple of months ago. I think I had only like three or four gaming sessions with it before forgetting the whole thing. Recently my interest in graphics stuff has been on the rise again (my interests are clearly cyclic web, graphics programming, FPGAs, other electronics, audio programming , mobile programming, photography, travelling, mountains, staring at an empty wall – add one more a year, drop one, rinse and repeat) and decided to pick up the Kinect from gathering dust.
So here’s a quick thingy I made (with Qt of course) last night:
The shortness and occasional bad framerate of the video are because of the capture tool.
I’ve got all sorts of wacky ideas I can implement with the Kinect, so more stuff coming later.
A while ago Razvanpetru asked on #qt-symbian@freenode (you should come there too) how to use the Symbian camera application in a Qt app. So I wrote a small QML friendly Qt wrapper class to hide the nitty-gritty Symbian details. You can download the package here.
Allrighty. In the last two posts (here and here) we laid the foundations for a rudimentary QML view framework. This time we add some simple context sensitivity to the UI and finalize the amazing KittyApp. Oh yeah, about that neat performance trick I promised in the first post – well I’m breaking my promise. I’ll write about it in a separate post.
This time we will improve our little view framework by adding on demand loading of the views.
For your app to have a decent startup time you can’t load all of your QML at one go when your app starts up. You might get away with it if you have a very simple app, but once you start adding more and more views which might contain images (these too will get loaded right away) you’ll end up in trouble.
Ok, this post (and the parts coming – I’ll just split this so that it won’t become a too long read) might interest a bit more wider audience than the previous ones.
So once you’ve started with QtQuick, played around with the examples, maybe done some own UI components and a few views, the thing you start wondering is “so how am I supposed to tie all this together to make it an application?” QtQuick itself doesn’t come with any kind of application framework. Just the basic building blocks you’ve seen in the examples. I (and Wolfgang here) think it’s a great thing that it doesn’t, because such a framework can go wrong in so many ways and restrict innovation. Naturally that would also be against the QtQuick philosophy of being just a framework for constructing objects easily and declaring interactions. Of course you usually still need to have one and probably(?) the boys and girls in the QtComponents project are making one. But the best part is that even if what they are proposing doesn’t suit you, with QtQuick you can just toss it all and do it yourself with relatively little effort. I’m not saying an ubiquitous application/view framework doesn’t have merits, but for standalone apps which don’t need tight integration to other being able to roll your own in a few moments is pretty damn great.
Ok, there must be a million tutorials on how to make a pushbutton in QML, but I guess there’s room for one more and I’ll try to give some tips that are applicable elsewhere too.
Generally speaking there’s two roads you can take here. Either you draw the button base without any bitmapped graphics i.e. using a Rectangle element or use bitmaps with an Image or a BorderImage element. A Rectangle is faster to draw (might be close if you use rounded corners and the button isn’t too big), but using bitmapped graphics of course gives you the best control on the appearance of the button. If your graphic design is such that the button base contains a horizontally (and/or vertically) repeating part, going for the BorderImage is a nobrainer, because it allows you to determine the size of the button in QML. Hopefully the picture below will illustrate the issue:
Update: this is no longer needed with the latest Qt shipping with QtSDK 1.1 TP.
First of all the title is purposefully misleading. I just want to get a good Google pagerank and help people find this page The title is misleading, because this is not QtQuick/QML specific, but applies to any drawing done with QPainter.
So all you have to do to supercharge the drawing of your Qt/QtQuick app is call QApplication::setGraphicsSystem() before constructing your QApplication. After doing so all painting done via QPainter will be automagically executed on the GPU.