Open Radar

 
Summary:

Scrolling of an NSTableView using views (instead of cells) bogs down when it is layer-backed. Observed on Lion (10.7.5) and Mountain Lion (10.8.1).

Steps to Reproduce:

1. Create a view-based table*. This problem repros even with a stock text-based cell view. Make sure the window is NOT layer-backed initially.
2. Provide a very large number of rows (e.g. 5 million). Cell data does not matter.
3. Run, present view, and notice scrolling performance when "scrubbing" the scrollbar with the knob.
=> observe that scrolling is highly responsive
4. Now go to the view and make the window's contentView layer-backed. Repeat test.

Expected Results:

=> Scrolling should still be very responsive.

Actual Results:

=> Scrolling performance becomes sluggish, lagging behind the knob position.

Regression:
N/A. View-based tables are new in Lion.

Notes:

* Performance appears to be proportional to the number of rows in the table -- NOT the number of rows visible on screen. Changing the row count to something more "reasonable" -- such as 500 -- mostly eliminates the lag.

* Debugger: the number of subviews of the NSTableView is reasonable (~ the number of rows visible in the window).

* The data source callbacks are all O(1).

* The "Time" profiler is inconclusive, showing lots of time spent in CA code.

* A simple sample project ("LayerBackedTableTest") is attached.