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…