Re: Drawing many different strings quickly

[Jens Alfke]

> On Oct 1, 2015, at 12:02 AM, Ben  wrote:
> 
> Using NSString's drawInRect:withAttributes: wants a Swift dictionary of 
> attributes. Instruments showed a lot of time spend accessing the elements of 
> this dictionary and converting back to Objective-C land.
> Converting the string to be drawn to an NSAttributedString and adding 
> attributes to it directly before drawing with drawInRect: resulted in string 
> drawing dropping from ~65% of drawRect time to ~50%.

Ah, that's interesting. So just passing a Swift Dictionary to an API that takes 
an NSDictionary triggers an expensive conversion. Sort of disheartening, at 
least to me (I spend more time than most of you having to worry about low-level 
performance issues.)

—Jens
___

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: Drawing many different strings quickly

[Ben]

> On 28 Sep 2015, at 18:42, Alex Kac  wrote:
> 
> We had the same question and I asked it at WWDC.  A few things I was told:
> 
> 1. El Capitan improves string drawing performance tremendously. That may 
> solve your problem.
> 2. They recommended in our case actually using NSTextFields for each string. 
> They showed me an app that had thousands of NSTextFIelds in a resizable 
> window and it was buttery smooth. Smoother than the same code using NSString 
> drawing functions in the exact same scenario. 
> 
> Now 100,000 strings may change the equation a bit…but might be worth a quick 
> try.
> 
> Alex Kac - El capitán


Just for a final follow-up now El Capitan is public.

0. I really am not trying to draw the whole view at once. It's just that you 
can scroll the whole grid vertically or horizontally in a single flick on a 
trackpad in about a second.

1. I should have mentioned that I am writing in Swift. I've become so 
accustomed to it that it's easy to forget it still has some slower bits.
Using NSString's drawInRect:withAttributes: wants a Swift dictionary of 
attributes. Instruments showed a lot of time spend accessing the elements of 
this dictionary and converting back to Objective-C land.
Converting the string to be drawn to an NSAttributedString and adding 
attributes to it directly before drawing with drawInRect: resulted in string 
drawing dropping from ~65% of drawRect time to ~50%.

2. Upgraded to 10.11 overnight last night and ran the same profile again. 
drawRect now spends around 35% of time drawing strings. The calls underneath 
drawInRect look vastly different. Thank you to whoever put this work in at 
Apple.

Drawing speed of the control is now fine and scrolling is smooth. I will have a 
small play with drawing options in case there more headroom that can be quickly 
gained, but am currently very happy.

Thank you all for the assistance.

- 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: Drawing many different strings quickly

[Jens Alfke]

> On Sep 28, 2015, at 6:07 PM, dangerwillrobinsondan...@gmail.com wrote:
> 
> If not, NSImage has a nice API for drawing to the image context. Then you 
> just have an NSImage. Let AppKit do the work. It will cache the drawing of 
> that image until you change it. 

That would be trading CPU for RAM (worse, for GPU RAM), which comes with its 
own set of performance problems.

Also, last I heard, drawing text into offscreen buffers disables sub-pixel 
antialiasing. Not noticeable with retina displays, but not everyone has those 
yet.

Anyway, I still don't accept that drawing plain text in a scrolled view is too 
slow, unless the code is doing something wrong like trying to draw all 100k 
strings at once every time. I’d like to see the code behind the current 
implementation…

—Jens
___

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: Drawing many different strings quickly

[dangerwillrobinsondanger]

Are you trying to have selectable text?
If not, NSImage has a nice API for drawing to the image context. Then you just 
have an NSImage. Let AppKit do the work. It will cache the drawing of that 
image until you change it. 
You can assign that to a layer or use one for each string. 

+ (NSImage *)imageWithSize:(NSSize)size
   flipped:(BOOL)drawingHandlerShouldBeCalledWithFlippedContext
drawingHandler:(BOOL (^)(NSRectdstRect))drawingHandler

Sent from my iPhone

> On Sep 29, 2015, at 6:11 AM, Ben  wrote:
> 
> 
>> On 28 Sep 2015, at 17:08, Jens Alfke  wrote:
>> 
>> 
>>> On Sep 28, 2015, at 1:41 AM, Ben >> > wrote:
>>> 
>>> 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.
>> 
>> As various people have said, there is no reason to draw any text that’s 
>> outside the dirtyRect passed to your -drawRect: call. So you never need to 
>> draw 100k strings at once. I’m confused by your statements in this thread ― 
>> you do say that you abide by the dirtyRect, so why are you drawing so many 
>> strings?
>> 
>>> Unfortunately NSTableView doesn't offer the type of interactions I want. I 
>>> have filed a radar requesting enhancements.
>> 
>> It’s very customizable. What’s missing for you?
> 
> I am sorry for the poor explanations. I hope this clears up my phrasing:
> 
> I am only drawing the area requested by the dirtyRect parameter.
> I mention the large number of strings since when scrolling I am being asked 
> to draw a larger number of dirtyRect blocks in quick succession. This means a 
> correspondingly larger number of strings to be drawn.
> 
> True, they are not all in the same drawRect call, but in sufficiently close 
> proximity that I thought speeding up the largest consumer of cpu time (ie. 
> string drawing) would help the improve the scroll lag.
> 
> 
> The biggest thing missing for me in NSTableView is single-cell selection and 
> highlighting. There was also a drawing bug which I filed a radar for. 
> 
> 
> ―
> 
> Thank you all for the suggestions though, I will try each of them.
> 
> ___
> 
> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.com
___

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: Drawing many different strings quickly

[Graham Cox]

> On 28 Sep 2015, at 6:41 pm, Ben  wrote:
> 
> 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.
> 


Another option is to use CATextLayer for each string. I believe this uses Core 
Text for layout, but the resulting image is aggressively cached to the GPU, so 
a given string is only ever rendered once. The layer drawing system takes care 
of optimising the actual drawing calls, so you are relieved of that task.

These days a scroll view is layer backed by a tiling layer by default, so using 
CATextLayers in this way should give you about as fast a drawing system as is 
currently possible.

—Graham



___

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: Drawing many different strings quickly

[Ben]

> On 28 Sep 2015, at 17:08, Jens Alfke  wrote:
> 
> 
>> On Sep 28, 2015, at 1:41 AM, Ben > > wrote:
>> 
>> 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.
> 
> As various people have said, there is no reason to draw any text that’s 
> outside the dirtyRect passed to your -drawRect: call. So you never need to 
> draw 100k strings at once. I’m confused by your statements in this thread — 
> you do say that you abide by the dirtyRect, so why are you drawing so many 
> strings?
> 
>> Unfortunately NSTableView doesn't offer the type of interactions I want. I 
>> have filed a radar requesting enhancements.
> 
> It’s very customizable. What’s missing for you?

I am sorry for the poor explanations. I hope this clears up my phrasing:

I am only drawing the area requested by the dirtyRect parameter.
I mention the large number of strings since when scrolling I am being asked to 
draw a larger number of dirtyRect blocks in quick succession. This means a 
correspondingly larger number of strings to be drawn.

True, they are not all in the same drawRect call, but in sufficiently close 
proximity that I thought speeding up the largest consumer of cpu time (ie. 
string drawing) would help the improve the scroll lag.


The biggest thing missing for me in NSTableView is single-cell selection and 
highlighting. There was also a drawing bug which I filed a radar for. 


—

Thank you all for the suggestions though, I will try each of them.

___

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: Drawing many different strings quickly

[Quincey Morris]

On Sep 28, 2015, at 01:41 , Ben  wrote:
> 
> Unfortunately NSTableView doesn't offer the type of interactions I want. I 
> have filed a radar requesting enhancements.

What about a hybrid approach? Use a NSTableView to draw the strings as a 
background “layer” of your scroll view, and put a sibling view on top of it 
that handles your interactions.

This should be pretty easy if the interactions involve only the grid cells, 
since their geometry is easy to calculate on the fly. If users need to interact 
with the text itself (e.g. if they can select portions of the strings), it 
would be harder, but you could try an approach analogous to a field editor: a 
temporary overlay view on the cell or row that’s being interacted with.

If you must deal with the performance yourself, then you could drop down to 
CoreText and bypass as much of the machinery as possible. CTLine probably 
contains everything you need, if you’re not trying to cache anything (except 
the CTLineRefs themselves, which may be feasible, since you’re using gobs of 
memory anyway). But remember that CTLine utility functions that do layout will 
create CTTypesetters, and that’s the expensive part.

Or you can try something clever like “batching” strings as paragraphs in a 
larger string, cacheing CTTypesetters for the larger strings, and spinning off 
individual CTLineRefs as needed for drawing.

___

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: Drawing many different strings quickly

[Jens Alfke]

> On Sep 28, 2015, at 1:41 AM, Ben  wrote:
> 
> 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.

As various people have said, there is no reason to draw any text that’s outside 
the dirtyRect passed to your -drawRect: call. So you never need to draw 100k 
strings at once. I’m confused by your statements in this thread — you do say 
that you abide by the dirtyRect, so why are you drawing so many strings?

> Unfortunately NSTableView doesn't offer the type of interactions I want. I 
> have filed a radar requesting enhancements.

It’s very customizable. What’s missing for you?

—Jens
___

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: Drawing many different strings quickly

[Aandi Inston]

I'd like to suggest a different approach if things cannot be tuned to have
far fewer draw calls. Font caching etc. is very fast, but not as fast as it
could be given the choices it has to support. I think you said you had one
font, one size. I'm guessing you also have no more than 256 different
characters you might show (but consider where in the world your customers
are...)

If so, perhaps you could simply have a table of 256 images, and paint them
to screen in the fastest possible way. Now, that's a lot of code to write
speculatively, but you can see if it will save time by replacing every
paint text call with a call to paint a single fixed image. If it goes fast
enough it may be worth this approach. (I'm sure there are fast and slow
ways to paint images too: grid aligned, unscaled, colour model matching -
maybe some of these can be optimized. Monochrome mask painting might be
faster, or slower).
___

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: Drawing many different strings quickly

[Ben]

> On 27 Sep 2015, at 19:26, Quincey Morris 
>  wrote:
> 
> On Sep 27, 2015, at 10:42 , Ben  > 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

Re: Drawing many different strings quickly

[Jens Alfke]

Use an NSTableView. It knows how to manage unlimited numbers of rows 
efficiently.

--Jens
___

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: Drawing many different strings quickly

[Graham Cox]

Hi Ben,

You may find that responsive scrolling is actually making things worse in this 
case, because many more strings than you can see are being drawn, and string 
drawing is expensive. Have you tried opting out of responsive scroling?

Apart from that, usual advice applies - draw the very minimum you need for the 
dirty area of the view. Strings are problematic, in that the bounding rectangle 
is hard to know in advance - calculating that requires the string be laid out, 
and there goes your time. Note that [NSString drawInRect:attributes:] creates a 
NSLayoutManager and associated components, does the drawing, then discards all 
the layout stuff, so it’s very inefficient. Your idea of reusing a 
NSLayoutManager for all your strings should give better performance, because a) 
you’re not recreating it every time and b) it caches quite a lot of layout info 
between calls (which is why you saw a speed up when the strings were the same).

You could try some additional caching of your own, e.g. the bounding rect of a 
known string, so that you can tell without needing layout again whether the 
string intersects the dirty region of the view (as tested by -needsToDrawRect:, 
not whether it intersects the overall dirtyRect). This is only worthwhile if 
your strings are repeated frequently enough, it’s not going to help if they’re 
all different. You could also try precalculating the bounding rects on a 
separate thread rather than doing that as part of drawing/scrolling so that the 
drawing part isn’t held up by the calculation. It can mean labels “pop in” to 
view as you scroll which might be unacceptable.

Getting this to perform well is hard, but it can be done. One of my apps draws 
maps which can consist of many, many thousands of textual labels drawn at 
arbitrary positions in varying styles. Using tricks as described it scrolls 
smoothly.

—Graham


> On 28 Sep 2015, at 3:42 am, Ben  wrote:
> 
> Hi list,
> 
> I'm needing to draw somewhere in the order of 1,000,000 different strings in 
> a scrollable grid view and am struggling to get performance that I am happy 
> with.
> 
> After profiling, most of my time is spent in drawing text into the view.
> 
> My first attempt was simply to use NSString's drawInRect:withAttributes:. The 
> attributes dictionary was cached between calls. This is not too bad for 
> shorter strings, but slows down dramatically once longer strings need to be 
> drawn truncated.
> 
> My second attempt has been to use my own 
> NSTextStorage/Container/LayoutManager trio and draw using NSLayoutManager. 
> This is faster when many strings are the same, but worse when most are 
> different. I don't know in advance what the strings will be so must assume 
> they are all unique.
> 
> 
> Can anyone suggest what I should look into next? My requirements are as 
> follows:
> 
> - Assume around a million unique strings to be drawn
> - 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
> - Longer strings will be truncated to a single line under 200px wide
> - All strings to be drawn in the same font/size/colour
> - I can target the current (or current+1) OS version if that makes any 
> difference
> 
> 
> Any pointers or suggestions gratefully accepted!
> 
> - 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/graham.cox%40bigpond.com
> 
> This email sent to graham@bigpond.com


___

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: Drawing many different strings quickly

[Quincey Morris]

On Sep 27, 2015, at 10:42 , Ben  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.

___

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

Drawing many different strings quickly

[Ben]

Hi list,

I'm needing to draw somewhere in the order of 1,000,000 different strings in a 
scrollable grid view and am struggling to get performance that I am happy with.

After profiling, most of my time is spent in drawing text into the view.

My first attempt was simply to use NSString's drawInRect:withAttributes:. The 
attributes dictionary was cached between calls. This is not too bad for shorter 
strings, but slows down dramatically once longer strings need to be drawn 
truncated.

My second attempt has been to use my own NSTextStorage/Container/LayoutManager 
trio and draw using NSLayoutManager. This is faster when many strings are the 
same, but worse when most are different. I don't know in advance what the 
strings will be so must assume they are all unique.


Can anyone suggest what I should look into next? My requirements are as follows:

- Assume around a million unique strings to be drawn
- 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
- Longer strings will be truncated to a single line under 200px wide
- All strings to be drawn in the same font/size/colour
- I can target the current (or current+1) OS version if that makes any 
difference


Any pointers or suggestions gratefully accepted!

- 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