Op 21/01/2016 om 00:45 schreef Andrew den Exter:
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 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é
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
