On Tue, Feb 8, 2011 at 4:21 AM, <[email protected]> wrote: >> -----Original Message----- >> From: ext Adriano Rezende [mailto:[email protected]] >> Sent: Tuesday, 8 February 2011 1:57 AM >> To: Jones Martin (Nokia-MS-Qt/Brisbane) >> Cc: [email protected] >> Subject: Re: [Qt-qml] ListView (optimization flags) >> >> Probably the delegates I use fits in the last case, since the >> performance difference is significant in those devices. But I'll port >> the implementation to QML, so we can have a better comparison using >> property bindings. >> >> Regarding the number of binding evaluations, wouldn't be the same >> number in both cases? For example, in the current implementation it >> creates the delegate and evaluates the bindings in component >> completion. In the recycle approach it wouldn't just evaluates the >> same bindings without the creating the delegate? > > During component creation QML delays much of the binding evaluation until the > component is complete. This prevents multiple redundant binding evaluations > form being performed while the component is initialized. If you have > multiple roles changing then some bindings may be evaluated multiple times. > This is of course dependent on the delegate implementation.
Indeed, this would avoid some intermediate evaluations during property initialization/changes. But maybe this bind delay could also be used while recycling a delegate. >> > Reuse would also not work if the delegates store any state - there is no >> > way to >> restore a delegate to its initial state. >> >> Delegate states should be binded to model properties, otherwise the >> state information would be lost after the delegate is destroyed. So, >> it's possible to reset to the initial state, since the initial state >> is dictated by the model data. But if you are talking about changing >> the delegate without keeping persistence in the model, even in this >> case a restoration is also possible using the clean signal and a >> delegate code with well defined states. > > I agree that it is worthwhile investigating this again. We simply didn't > pursue it at the time since it wasn't a straight forward gain and we had > other more pressing problems to solve (actually we spent a lot of time > minimizing component creation time since it both benefitted delegate creation > and QML loading in general). Yes, there are still more important issues than this one. I've just pointed this out as an improvement/investigation for future releases. Thanks for the explanation. Br, Adriano _______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
