-->

How to make NSTableView not reuse TableCellViews

2020-07-10 05:45发布

问题:

I would like my view-based-NSTableview to not reuse previously generated TableCellViews that are scrolled out of scope. I figure that this would be possible with UITableView by overwriting dequeueReusableCellWithIdentifier: to return nil. Ist there is similar solution for NSTableView?

-

My Background: I have a quite complex view-based-tableView bound to ManagedObjects in the usual way (i.e. table-content, -selection and -sortdescriptor are bound to an arraycontroller and the tableCellView-elements bind to the objectValue).

The table has about 20 columns but at most 400 rows. Scrolling is really slow, but time-profiling indicates that no single source of slowness exists (largest single method-call takes about 5% of time). After caching the derived/custom properties of my ManagedObject without much performance-boost, i'm now trying to cache the views (to avoid the frequent rebind of the tablecellViews when a view comes into scope).

What i'm trying at the moment is to not bind the table-content, but to get my views using the NSDatasource-protocol. There in

-(NSView*) tableView:(NSTableView *)tableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row

i would like to return cached TableCellViews if they exist. Otherwise i create a new one via

[self.table makeViewWithIdentifier:... owner:self];

Since makeViewWithIdentifier may return views that are already cached by me, the table-content gets messed up with wrong cells.

Performance is significantly better with this approach...

-

Other ideas on making scrolling more performant are also appriciated.

回答1:

In your tableView:viewForTableColumn: implementation set the .identifier on the returned view to nil. That will prevent the table from caching it. You could then manage your own cache. FWIW, you don't have to even use makeViewWithIdentifier: at all; you can just manually create your views from scratch, instead of using that method (which loads the pre-setup views form the NIB).

However, if you are having performance problems, it would be better to address those by looking at what is slow and why. You didn't provide information on why it is slow, so it is hard to say what to do. 20 columns is a lot. You might get better performance by attempting to reduce your layer count by using canDrawSubviewsIntoLayer, on the NSTableCellView, or the NSTableRowView. But there are lots of caveats and things to be aware of when doing this.

corbin