> On 2 Mar 2015, at 14:10, Mike Abdullah <mabdul...@karelia.com> wrote: > >> >> On 2 Mar 2015, at 11:44, Ben <ben_cocoa_dev_l...@yahoo.co.uk> wrote: >> >> Hi list, >> >> Since NSCell is apparently on the way out, I've been trying to build a new >> control I need using views. It's a cut-down spreadsheet-alike grid, similar >> to MBTableGrid here: https://github.com/brendand/mbtablegrid >> >> Unfortunately, I am running into the to-be-expected performance trouble with >> keeping a couple of hundred subviews in my control at the same time. It >> particularly hurts when scrolling. Stuff I've tried includes: >> >> - Removing the off-screen views when possible (still leaves about 150 on >> screen) >> - Keeping a queue of reusable views to avoid allocating new ones >> - Attempting to have one view per grid item type and treat it like an NSCell >> (i.e., lockFocus into the parent view and draw there) >> >> Clearly a smooth-scrolling view-based grid is possible - after all, >> NSTableView can do it. It's a shame I can't use it for this. >> >> Does anyone have any suggestions on how to achieve decent drawing/scrolling >> performance here? > > Can you offer any more explanation as to *what* is slow in your experiments? > What is about the number of views that seems to be bogging your control down?
Certainly: From a time profile, the majority of my code being called is funnelled through a single method which handles the adding/positioning/removing of views within the visible area. The slow areas are: 8% - Instantiating new views (happens early on, views are cached for reuse) 20% - Positioning new/reused views (a single -setFrame: call once for each view) 25% - Adding newly-visible subviews (-addSubview:) 17% - Enumerating off-screen columns for view removal (-removeFromSuperviewWithoutNeedingDisplay) 25% - Enumerating off-screen rows for view removal (-removeFromSuperviewWithoutNeedingDisplay) Remainder is misc small stuff. This method as a whole takes 19% of running time. The grid typically has up to 50 columns and 1000 rows. There is a hard upper limit of 2000 columns and no reasonable limit on rows. I intend to paginate these. In my test project, I am assuming around 10 columns and 40 rows visible, giving 400 views visible. Maybe slightly more to allow for those just offscreen. None of the above even begins to think about memory usage (Idle ~40MB, under fast scrolling up to 300MB) Thanks, Ben _______________________________________________ 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
