On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly <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. Andrew
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
