Re: Responsive scrolling control with lots of subviews

[Corbin Dunn]

> On Mar 2, 2015, at 10:26 AM, Ben  wrote:
> 
> 
>> On 2 Mar 2015, at 17:42, Quincey Morris 
>>  wrote:
>> 
>> On Mar 2, 2015, at 02:44 , Ben > > wrote:
>>> 
>>> 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
>> 
>> I don’t see that anyone has yet asked the question of why the grid needs to 
>> have subviews. Implementing the rows and columns yourself means inventing 
>> your own duplicate API for managing them, but it’s likely not a lot of code, 
>> assuming you only need textual editing of one cell at a time (and can 
>> therefore use a single re-usable, movable text field for the editing).
>> 
>> So, why can’t your spreadsheet-like grid be a single custom view that draws 
>> its own text and graphics in a grid-like pattern directly?
>> 
>>> PS. I have tried using/subclassing NSTableView and have filed a bug for the 
>>> functionality that I'm after
>> 
>> Purely for interest’s sake, can you tell us what functionality is missing, 
>> for your use-case?
>> 
> 
> 
> I hadn't considered asking my delegate for text and images directly. That 
> could be a simpler way to do things - I will look into it.
> 
> 
> The functionality that I'm missing is:
> 
> - Granularity of selection. For example single or multiple disconnected 
> cells. NSTableView only gives me row or column.
> - Scrollable floating headers on both axis. This I did sort-of manage with 
> NSTableView by styling the first column to look like a header, but it was not 
> great.

Did you indeed log bugs for these requests? I haven’t seen any come in for 
them. Please give me the radar #’s.

thanks!

corbin


___

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

Re: Responsive scrolling control with lots of subviews

[Ben]

> On 2 Mar 2015, at 19:10, Uli Kusterer  wrote:
> 
> On 02 Mar 2015, at 19:26, Ben  wrote:
>> - Granularity of selection. For example single or multiple disconnected 
>> cells. NSTableView only gives me row or column.
>> - Scrollable floating headers on both axis. This I did sort-of manage with 
>> NSTableView by styling the first column to look like a header, but it was 
>> not great.
> 
> So you're effectively implementing something like a spreadsheet?

Sort of, yes. Basically it's for browsing database contents with more focused 
UI selections than a simple table offers. The problem is that when you begin by 
saying "spreadsheet", so many people jump to the conclusion "you're building 
Excel and a fancy calculation engine too!". I am sorry if my writing has lead 
anyone in the wrong direction.

Incidentally, since you and Ken Thomases mentioned it, by responsive scrolling, 
I meant the "smooth 60fps" type of responsive. However, I am taking into 
account the capital-R Responsive guidelines for over-drawing and preparing 
contents outside the user-visible area.


Thank you all for the pointers though. It's getting late here, but I will 
continue my work tomorrow.

- 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

Re: Responsive scrolling control with lots of subviews

[Uli Kusterer]

On 02 Mar 2015, at 19:26, Ben  wrote:
> - Granularity of selection. For example single or multiple disconnected 
> cells. NSTableView only gives me row or column.
> - Scrollable floating headers on both axis. This I did sort-of manage with 
> NSTableView by styling the first column to look like a header, but it was not 
> great.

 So you're effectively implementing something like a spreadsheet?
___

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

Re: Responsive scrolling control with lots of subviews

[Uli Kusterer]

On 02 Mar 2015, at 17:43, Ken Thomases  wrote:
> On Mar 2, 2015, at 9:45 AM, Uli Kusterer  wrote:
> 
>> Are you re-setting *all* the views or only hiding views that scroll out and 
>> moving unused views to newly exposed areas? We've been doing stuff like that 
>> in various spots and performance is fine. One thing that might help is to 
>> make each table-row layer-backed, then you get zero-cost moving as it simply 
>> gets drawn in another location on the graphics card. …
>> 
>> - Make all rows layer-backed
> 
> Careful.  As noted in my previous reply, if you use layer-backed views, the 
> root layer must be the scroll view or an ancestor.  Making only the rows 
> layer-backed will disable responsive scrolling.

I read it as lowercase "responsive scrolling", not Apple's "Responsive 
Scrolling" feature that pre-loads complicated stuff like maps in the 
background. I was mainly listing what we actually do and works for us, we've 
never needed Apple's Responsive Scrolling to have responsively scrolling lists.
___

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

Re: Responsive scrolling control with lots of subviews

[Ben]

> On 2 Mar 2015, at 17:42, Quincey Morris  
> wrote:
> 
> On Mar 2, 2015, at 02:44 , Ben  > wrote:
>> 
>> 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
> 
> I don’t see that anyone has yet asked the question of why the grid needs to 
> have subviews. Implementing the rows and columns yourself means inventing 
> your own duplicate API for managing them, but it’s likely not a lot of code, 
> assuming you only need textual editing of one cell at a time (and can 
> therefore use a single re-usable, movable text field for the editing).
> 
> So, why can’t your spreadsheet-like grid be a single custom view that draws 
> its own text and graphics in a grid-like pattern directly?
> 
>> PS. I have tried using/subclassing NSTableView and have filed a bug for the 
>> functionality that I'm after
> 
> Purely for interest’s sake, can you tell us what functionality is missing, 
> for your use-case?
> 


I hadn't considered asking my delegate for text and images directly. That could 
be a simpler way to do things - I will look into it.


The functionality that I'm missing is:

- Granularity of selection. For example single or multiple disconnected cells. 
NSTableView only gives me row or column.
- Scrollable floating headers on both axis. This I did sort-of manage with 
NSTableView by styling the first column to look like a header, but it was not 
great.

Maybe I will have another look at digging into NSTableView again.


___

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

Re: Responsive scrolling control with lots of subviews

[Quincey Morris]

On Mar 2, 2015, at 02:44 , Ben  wrote:
> 
> 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

I don’t see that anyone has yet asked the question of why the grid needs to 
have subviews. Implementing the rows and columns yourself means inventing your 
own duplicate API for managing them, but it’s likely not a lot of code, 
assuming you only need textual editing of one cell at a time (and can therefore 
use a single re-usable, movable text field for the editing).

So, why can’t your spreadsheet-like grid be a single custom view that draws its 
own text and graphics in a grid-like pattern directly?

> PS. I have tried using/subclassing NSTableView and have filed a bug for the 
> functionality that I'm after

Purely for interest’s sake, can you tell us what functionality is missing, for 
your use-case?



___

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

Re: Responsive scrolling control with lots of subviews

[Ken Thomases]

On Mar 2, 2015, at 9:45 AM, Uli Kusterer  wrote:

> Are you re-setting *all* the views or only hiding views that scroll out and 
> moving unused views to newly exposed areas? We've been doing stuff like that 
> in various spots and performance is fine. One thing that might help is to 
> make each table-row layer-backed, then you get zero-cost moving as it simply 
> gets drawn in another location on the graphics card. …
> 
> - Make all rows layer-backed

Careful.  As noted in my previous reply, if you use layer-backed views, the 
root layer must be the scroll view or an ancestor.  Making only the rows 
layer-backed will disable responsive scrolling.

Regards,
Ken


___

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

Re: Responsive scrolling control with lots of subviews

[Ken Thomases]

On Mar 2, 2015, at 8:54 AM, Ben  wrote:

> 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.

What are you considering "visible" or "the visible area"?  For responsive 
scrolling, you don't want to limit it to the document view's visible rect.  You 
want to use the preparedContentRect and override -prepareContentInRect: to be 
told when that is changing.

Review this list of the "secondary" requirements to participate in responsive 
scrolling, from the AppKit release notes for 10.9 (not currently available 
online):

The list of secondary requirements are:

* Do not override -scrollWheel: in an NSScrollView, NSClipView subclass, or in 
the document view. (See the event modal notes in this section)

* Do not override -drawRect: in an NSScrollView subclass

* Do not override -lockFocus: in an NSScrollView, NSClipView subclass, or in 
the document view.

Layer backed secondary requirements:

* The root layer must be either the NSScrollView or an ancestor view

Traditional drawing secondary requirements:

* copiesOnScroll must be set to YES on the NSClipView

* The documentView must override -isOpaque and return YES

Regards,
Ken


___

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

Re: Responsive scrolling control with lots of subviews

[Ben]

> On 2 Mar 2015, at 15:45, Uli Kusterer  wrote:
> 
> On 02 Mar 2015, at 15:54, Ben  > wrote:
>>> On 2 Mar 2015, at 14:10, Mike Abdullah >> > wrote:
 On 2 Mar 2015, at 11:44, Ben >>> > 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.
> 
> Are you re-setting *all* the views or only hiding views that scroll out and 
> moving unused views to newly exposed areas? We've been doing stuff like that 
> in various spots and performance is fine. One thing that might help is to 
> make each table-row layer-backed, then you get zero-cost moving as it simply 
> gets drawn in another location on the graphics card. My checklist for a 
> view-based table view would be:
> 
> - Create (height/ row height) +1 row views and keep them around
> - Make all rows layer-backed
> - When scrolling, make sure you only modify the position, not the height, and 
> do not call setNeedsDisplay: on any views whose contents haven't actually 
> changed
> - when a view goes out of view, re-use it for the newly-exposed area, and 
> only then request a redraw, or otherwise hide it.
> - Mark as many views as you can as opaque.
> - Try to update items relatively to each other. I.e. just assume the 
> bottom-most view is already positioned right and place the newly-exposed 
> row's view under it, don't loop over all rows over and over again.
> 
> That said, we used to do the same without layer-backing in the Carbon and 
> Classic days and Macs had sufficient performance, so that this is taking too 
> long for you seems weird. Are these custom views? Are you rounding 
> coordinates to integers to ensure they don't subtly change size due to 
> rounding errors?
> 
> Also, I remember using PXListView (https://github.com/Perspx/PXListView 
> ) a few years ago and contributing a 
> bunch of performance fixes. It's not the code we're using these days (and it 
> has changed a bit since then), but it might do one or the other optimization 
> you're not doing, so may be a good point of reference.

Thanks for the pointers and link, there are a few of these I'm not doing yet so 
will give them a try.

- 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

Re: Responsive scrolling control with lots of subviews

[Uli Kusterer]

On 02 Mar 2015, at 15:54, Ben  wrote:
>> On 2 Mar 2015, at 14:10, Mike Abdullah  wrote:
>>> On 2 Mar 2015, at 11:44, Ben  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.

Are you re-setting *all* the views or only hiding views that scroll out and 
moving unused views to newly exposed areas? We've been doing stuff like that in 
various spots and performance is fine. One thing that might help is to make 
each table-row layer-backed, then you get zero-cost moving as it simply gets 
drawn in another location on the graphics card. My checklist for a view-based 
table view would be:

- Create (height/ row height) +1 row views and keep them around
- Make all rows layer-backed
- When scrolling, make sure you only modify the position, not the height, and 
do not call setNeedsDisplay: on any views whose contents haven't actually 
changed
- when a view goes out of view, re-use it for the newly-exposed area, and only 
then request a redraw, or otherwise hide it.
- Mark as many views as you can as opaque.
- Try to update items relatively to each other. I.e. just assume the 
bottom-most view is already positioned right and place the newly-exposed row's 
view under it, don't loop over all rows over and over again.

That said, we used to do the same without layer-backing in the Carbon and 
Classic days and Macs had sufficient performance, so that this is taking too 
long for you seems weird. Are these custom views? Are you rounding coordinates 
to integers to ensure they don't subtly change size due to rounding errors?

Also, I remember using PXListView (https://github.com/Perspx/PXListView 
) a few years ago and contributing a 
bunch of performance fixes. It's not the code we're using these days (and it 
has changed a bit since then), but it might do one or the other optimization 
you're not doing, so may be a good point of reference.

Cheers,
-- Uli
http://stacksmith .org
___

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

Re: Responsive scrolling control with lots of subviews

[Ben]

> On 2 Mar 2015, at 14:10, Mike Abdullah  wrote:
> 
>> 
>> On 2 Mar 2015, at 11:44, Ben  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

Re: Responsive scrolling control with lots of subviews

[Steve Mills]

On Mar 2, 2015, at 08:25:05, Steve Mills  wrote:
> 
> Have you profiles it to see what's taking all the time?

Yerg. "profiled"

--
Steve Mills
Drummer, Mac geek

___

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

Re: Responsive scrolling control with lots of subviews

[Steve Mills]

On Mar 2, 2015, at 04:44:12, Ben  wrote:
> 
> 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)

Have you profiles it to see what's taking all the time?

--
Steve Mills
Drummer, Mac geek


___

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

Re: Responsive scrolling control with lots of subviews

[Mike Abdullah]

> On 2 Mar 2015, at 11:44, Ben  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?


___

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