First, the row caching in general is one big magic chunk of code of which I'm not sure if everything is even used.
Second there is a bug in CPTableColumn _newDataViewForRow. The code there asks the tableview for it's cached dataviews and always returns the last dataView. Effectively always reversing the dataviews used for each row. Example:
Row 0: dataview 1
Row 1: dataview 2
Row 2: dataView 3
After reloadData this becomes:
Row 0: dataview 3
Row 1: dataview 2
Row 2: dataview 1
I've tried fixing this by removing the first item of the cachedDataViews but it doesn't work. Like I said at the start there is just to much caching stuff going on in various places for any fix (except a rewrite) to be reliable.
I don't quite see how the caching thing is a bug. The order the cached views are used in doesn't seem particularly important.
_cachedDataViews is not really the equivalent of a dataview prototype. I'm removing my comment because i don't want to add confusion to this already complex debate. Hope it's OK.
We'll never be able to magically cache the views returned from such a delegate method. The solution will have to be caching by identifier, like in the iPhone table view world.
This definitely causes a bug because if you go into editing mode on a cell, then resize the entire window, you'll see the editing cell jump up and down as you resize because of the reordering issue. We need to at least lock the editing cell from being recycled, this is important for me especially because I'm using variable row heights and growing a row while editing it causes it to jump also.
This is also an issue with dataview that contains controls.
If the textfield in the last row is first responder and data is reloaded the dataview moves to row 0 because the dataview still contains the same textfield the first responder state will appear to have jumped (assuming that the textfield is an instance variable or ephemeral subview).
This is also an issue because caching isn't very useful if on every reload a different view is returned. The tableview will change the object value of the view and the view will have to redraw and relayout reducing the effectiveness of caching all together.
Like I said in the original ticket the caching behavior of CPTableView is a bit of a mess currently. There are a lot of different places where cells are created / cached.
I believe a complete rewrite of the caching system by a single person or a couple of persons communicating heavily is the best solution right now. Before that we should probably discuss what should be cached, when it should be cached and where it should be cached. Shall I open a discussion on the mailing list for this?
Milestone: 1.0. Labels: #accepted, #needs-patch, #needs-reduction, AppKit, bug. What's next?
Browsing through the commit logs I can see that _newDataViewForRow:column has been rewritten in the interim.
If there is a specific performance problem with the new implementation then a new issue should be opened. For now, I'll close this.
Milestone: 1.0. Labels: #fixed, AppKit, bug. What's next? This issue is considered successfully resolved.