> On 27 Sep 2015, at 19:26, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Sep 27, 2015, at 10:42 , Ben <ben_cocoa_dev_l...@yahoo.co.uk > <mailto:ben_cocoa_dev_l...@yahoo.co.uk>> wrote: >> >> - Not all strings to be drawn at once, a scroll view is being used and I am >> using responsive scrolling to pre-draw areas. The problem occurs when >> quickly scrolling a large distance > > I think your answer is in this statement. Assuming you’re drawing the strings > in drawRect of a custom view, and the size and position of the grid cell > containing each string doesn’t depend on the metrics of any other string, > then the cost of this kind of interface is the number of strings you can > *see* at once (less than 50 surely), not the number of strings in your data > model. Responsive scrolling may make the smaller number a bit larger, but if > you’re getting performance problems from this, you’re likely doing something > wrong. > > But … > >> The problem occurs when quickly scrolling a large distance > > There it is, really. What I said before applies only when the scrolled view > isn’t scrolling. When it is, you can *see* many more strings at essentially > the same time. > > What’s the answer to this question: If you quickly scroll across 10,000 > strings, how many strings is your drawRect drawing? 10,000? Less? More? You > need to do some analysis to find out what you’re actually doing. > > Are you using the dirtyRect parameter of drawRect to limit which strings you > draw? Are you using ‘getRectsBeingDrawn:count:’ or ‘needsToDrawRect:’ to > limit drawing even further? Have you tried using a table view? > > Ultimately, if your drawing technique can’t keep up with fast scrolling, > you’re going to have to *stop* drawing when it starts to lag, and catch up > when scrolling slows or stops. > > P.S. You didn’t say whether this is OS X or iOS. I think responsive scrolling > is OS X only, so I’m guessing that’s the platform.
Thank you for the quick response. This question is regarding OS X. As you mention, drawing a static visible area is absolutely fine. The system requests me to draw a certain amount of extra area ready for scrolling and I mark that as prepared. This area then isn't asked to be drawn when scrolling begins. The control is only drawing the areas requested by the dirtyRect parameter. Typically this is an area of (I think - going by memory) 256px square at a time. When looking at the result of getRectsBeingDrawn, there is only one rect the same as the dirtyrect. When scrolling vertically, there could be up to 100,000 strings to be drawn, horizontally, much fewer, less than 10,000. I'm assuming a maximum grid size of 100 columns and 10k rows. This should be a worst-case assumption. I hadn't considered skipping some draw calls. I could perhaps just draw row backgrounds and add text when the lag ends. Unfortunately NSTableView doesn't offer the type of interactions I want. I have filed a radar requesting enhancements. Thanks again, 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
