Quick post on QML scrolling performance

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…

This entry was posted in Programming and tagged , , . Bookmark the permalink.

4 Responses to Quick post on QML scrolling performance

  1. @arhzu says:

    In a typical ListView based application, I guess the QGV painting takes about 6-10 ms. That leaves a good 5ms for extra stuff, like creating new delegates… However, unless your delegate is very simple, you will not make it in 5 ms, it’s more like 16-20 ms usually. It’s actually quite hard to optimize once you reach certain level of complexity. Small amounts of time go to text layout, binding evaluation, text re-layout if the anchors changed the Text width, more binding evaluation, some slow bindings there that the optimizer did not catch, one onCompleted signal step to javascript because there is this one thing that you just cannot do without, and by the way an async Image was just loaded, scrap the previous thing and evaluate some more bindings. Little things pile up in the construction.

    The QML performance analyzer in QtCreator can help figuring out why something is slow. However, it won’t tell you if you are painting the screen many times over with Rectangles, or clipping where z-order would be enough.

    One difference between LMT and QML might come from delegate recycling. In LMT, I believe, it could be possible to keep the items alive in the scene, just change the data. QML, on the other hand, starts from scratch every time.

  2. I understand that real world scenarios are complex, but the real beauty of QML is its elegance and ease of use, where too much of anything will be a confusion. So my conclusion would be to make use of Qt in order to handle complex scenarios. I don’t think too many developers will have to go for Qt since QML does a fair job for most cases. But things like these will be useful too.

    And don’t think that it less hot after 2 eleven. Its not! :)

  3. ss says:

    I am really delighted to read this website posts which consists of lots of useful
    information, thanks for providing such data.

  4. FirstBridget says:

    I see you don’t monetize your page, don’t waste your traffic, you can earn extra bucks every month because you’ve got
    high quality content. If you want to know how to make extra bucks, search for: Mrdalekjd methods for $$$

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>