On 21/01/16 00:45, Andrew den Exter wrote:
On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly
<stephen.ke...@ableton.com <mailto:stephen.ke...@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.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
