[Qt-qml] ListView (optimization flags)

[martin.jones at nokia.com]

> -----Original Message-----
> From: ext Adriano Rezende [mailto:adriano.rezende at openbossa.org]
> Sent: Tuesday, 8 February 2011 1:57 AM
> To: Jones Martin (Nokia-MS-Qt/Brisbane)
> Cc: qt-qml at qt.nokia.com
> Subject: Re: [Qt-qml] ListView (optimization flags)
> 
> On Sun, Feb 6, 2011 at 9:00 PM,  <martin.jones at nokia.com> wrote:
> > We've done some preliminary experimentation with this, but it did not generally
> lead to an improvement because the case of item creation is optimized by delaying
> evaluation of bindings until component completion.
> > Changing a number of bindings (i.e. roles) on existing items can result in
> bindings being evaluated multiple times which can be costly, especially for text
> layout.  There are probably delegates which would see improvement from this and
> it is something we will revisit in the future.
> 
> 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.

> > 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). 

Br,
Martin.