[Development] Binding evaluation during ListView delegate remove animation

[Stephen Kelly]

On 21/01/16 00:45, Andrew den Exter wrote:
>
>
> On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly 
> <stephen.kelly at ableton.com <mailto:stephen.kelly at ableton.com>> wrote:
>
>
>>     And there are the obvious runtime costs to building and
>>     maintaining a cache that is of little or no use to most people
>>     most of the time, which is I think a strong argument for it being
>>     an off by default feature if implemented.
>>
>
>     I think the cost would need to be measured before letting it
>     influence design decisions. We are not talking about monstrous
>     amounts of data.
>
>
> Famous last words.  I have to assume any cache is going to be 
> pre-populated with data from every role

Wow, that sounds bad indeed.

My idea is to cache when the data is first requested in a memoizing 
design. All of those requests go through the same classes in the QML 
implementation.

<snip>

> any binding with a conditional statement in it opens up the 
> possibility that a role won't be accessed until after the row is removed

So you are thinking of QML code like this in a delegate:

  Text {
      text: someCondition ? model.someRole : model.otherRole
  }

Is that correct?

In that scenario, if someCondition is always true, then my memoization 
will cache the data for someRole, but not for otherRole.

Then, the row for that delegate gets removed and it gets animated away.

While it is animated away, someCondition becomes false, and the entire 
binding gets re-evaluated. Because the corresponding row is already 
gone, and because otherRole was never accessed while it was still there, 
the data for otherRole is not memoized, and we end up again with the a 
bug similar to what I posted on github with 'undefined' in the text field.

Thanks for pointing that out. It is a limitation of my proposal that 
conditionally accessed data can still cause artifacts.

So here's a summary of approaches possible for this class of bug:

* Cheap memoization
* Very expensive up-front cache population
* Somehow inspect bindings in delegates to find out what roles they 
could use
* Something else

For data which is conditionally accessed, the memoization does not fix 
everything, but up-front caching could.
For data which is not conditionally accessed, the memoization is enough.

We can try to decide what makes sense for QML to do.

Thanks,

Steve.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160121/027a17cb/attachment.html>