[tenfingers]

If you have a classical desktop interface where you reach 100+ widgets (which sounds like a lot but is easily reachable with just a toolbar, some buttons and a form), the difference is noticeable when interacting even on recent hardware (i5+).

For example, since I work in visualization, I often tie data widgets to the GL canvas in order to provide realtime feedback. I also use Qt5 in order to provide keyboard accelerators. With QT5 the rendering latency grew so high that I couldn't provide realtime feedback anymore, and I had to batch requests (and finally reverted to Qt4).

Incidentally Qt5 widgets can be used in a GL context directly, but are way too slow to render and manage events to be used consistently at 60 fps (they're not designed for that, so their scope in this sense is not as broad as it can really be). It's actually faster to give them their own GL context in order not to interfere with your pipeline, which kinds-of defeat the point.

I've also found that the additional JS glue doesn't provide any benefit unless you go entirely QML.

[CarVac]

Interesting.

What exactly is each 'widget' when you say there are 100+ widgets? Each overall feature, or each Item within the feature?

In my photo editor I have a histogram of how many photos you've taken each day: http://i.imgur.com/7yAYsP9.png

The histogram is actually a ListView, and each delegate is actually not just the bar for each date, but also the background color, the highlight color for the current date, and the date text that's above each bar. Using model updating, it responds nearly instantly even though there are a thousand days in the view, and the source data is a big ol' SQLite query with C++ postprocessing.

I don't know if that's helpful to you, though. Would that count as one widget in your parlance?

[tenfingers]

By Widget I mean any object which is a QWidget and is bound by some other widget (so I do not count plain QObjects) that you need for your UI.

ListViews are optimized for display of lists, obviously, so they generally instantiate only visible elements in the view, and delegates do not even undergo geometry negotiation so they're a bit lighter than a regular widget.

Still, if you do visualization or animation, the UI must respond within 1ms in order not to be noticeable, and that's very hard to attain with Qt5.

I doubt people using QML on mobile devices really understand the issue either, since when mobile developers speak of "animations" they generally mean some random transition of the UI itself. Often, the operation is not even performed in the background, but rather simply sequenced (so that the animation appears to be smooth, but the actual delay is completely absorbed by the user). In these scenarios, times up to 250ms/300ms might still be felt "instantaneous" as they're shorter than the transition. For me, it's outrageous.