[Development] Binding evaluation during ListView delegate remove animation

[André Somers]

Op 21/01/2016 om 00:45 schreef Andrew den Exter:
>
>
> 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 provided by the model and 
> refreshed every time dataChanged is emitted for that row, because the 
> views have no knowledge about what roles a delegate queries until 
> after the fact, and 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 making on access caching a flaky solution.  How third 
> parties implement their models and delegates is a big factor in the 
> potential cost of an effective cache, a model with many roles and 
> costly access to some of those but with a delegate that only accesses 
> a few in bindings may work fine now, but be absolutely hammered by an 
> aggressive cache.   And I obviously don't want to see views which 
> don't hit this relatively rare combination of circumstances pay that cost.
>
Actually, I think it would not need to be quite as bad.
For starters, you really only need to cache the actual items being 
removed. At the moment the model emits the AboutToBeRemoved signal, the 
data should still be there in any well-behaved model, right? _That_ is 
the moment you do your caching.

While it is possible that because of conditionals in the binding roles 
are accessed only during the removing, it does not sound very likely. 
One could provide an API to specifically add roles to the caching 
manually, but otherwise only cache roles that have been accessed 
already. Or just only set the roles manually and use that as the on/off 
switch for the whole feature that Andrew requested. Realistically, for 
most models, this would be something like perhaps an image and a couple 
of strings for an item. And these would only need to live for a short 
time, because once the remove animation is done, the data can be removed 
again.

I think it is certainly worthwhile to investigate.

André

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