On Feb 27, 2012, at 10:21 PM, Quincey Morris wrote:
On Feb 27, 2012, at 20:46 , Graham Cox wrote:
Jeez.
Indeed. Especially as it's usually taken as a given that large numbers of NSViews aren't going to perform well. Trying to make the scenario work might be quixotic at best.
However, two thoughts did spring to mind:
1. It might be easier (and faster) to just hide the subviews as they scroll out of the visibleRect, and show them as they scroll in. I'd *imagine* that lots of hidden views wouldn't be a big problem for drawing.
2. If the views are arranged linearly, which seems like one possible interpretation of the OP's scenario description, then it might be possible to use the new view-based NSTableView, since that configuration basically caches a small number of actual "cell" views even if the total number of cells is huge.
Or, if his situation can't be handled by a table view, then to create a custom enclosing view that at least adopts the model of only creating views/cells when they become visible and dispose of them when they scroll out of the view. The added benefit is reducing an app's memory footprint. (I've been doing iOS programming for the last while, so we think about things like this. :) ) steve _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com