Why the use of NSCell instead of CALayer on OS X?

[cognociente]

Like you, I implemented an NSView based spreadsheet-like grid only to find out that it wasn't performant. Initially I thought it was me but some searching the web has me more at ease that I was taking the wrong approach (NSViews). I'm now at the point where I am researching various alternative approaches. In particular, layers are a contender and given that you have a desire to port this to iOS (which is very layer oriented) I wondered why you went for cells instead?

[monyschuk]

CALayers were very heavy compared to views and cells in my experience when dealing with very large layouts. The process of adding and removing layers as they came into and went out of visible range within the scrolling view was eating significant time.

Here's a fullscreen grid of cells:

which in the layer case translates to over 1200 layers that need to be added and removed from the layer tree as we scroll. Ultimately, when I move this code to iOS, I suspect that what I'll do is build an object something akin to a cell and use that in a drawRect() there as well...

[monyschuk]

Some thoughts on making a cell or cell-like approach reasonably performant:

1. reuse a single cell like a rubber-stamp to draw content - there's little need for more than one
2. redraw only what's in the dirty rect
3. use layer backed views - your view will be rendered into blocks of 255x255 textures, tiled and reused by the system to minimize the amount of actual drawing code being executed.

[cognociente]

(1) "The process of adding and removing layers as they came into and went out of visible range within the scrolling view was eating significant time"... if you were reusing existing sections of the grid instead of adding/removing could that bring performance into an acceptable level? They would still need to be re-drawn with whatever is at the location BUT they wouldn't have to be de-allocated and allocated.

(2) "use layer backed views - your view will be rendered into blocks of 255x255 textures, tiled and reused by the system to minimize the amount of actual drawing code being executed."

• Are you suggesting a single layer-backed view containing all the cells.
• CALayer? CATiledLayer?or CAScrollLayer?
• Would/Could you draw the whole 16k columns x 1m rows in one shot and leave it up to the framework to intelligently only draw what is needed? (this would be a huge bonus)

[monyschuk]

In re. (1) - I've tried this and it was a bit of a bear... I might play around with some code to see if I might be able to pull it off reasonably, but found in past that special cases like resizing of a window causing a collection of layers coming into visible range ground performance down.

Regarding (2) - actually I'm just speaking of what's going on under the covers in the NSView machinery. When I create a large view in an NSScrollView, if I make it layer-backed then my drawRect: methods start being called in a systematic fashion - typically called in sequence with a series of 255x255 rects that correspond to the visible area plus any slop. So I'm not really doing anything special, but the view machinery under the hood is handling the tiling for me.. So long as my individual renders of any given rect passed to me is efficient, then the whole operation is very smooth.

[cognociente]

Chuckled at the expression "bit of a bear".