Actually, for source level questions the forums are just fine (preferred even, since then others can see the replies). I get notifications when there are new messages here or on github.
We haven't run up against this limit, though we expect it to to be an issue for longer blobs of text. This has been OK for our apps since they typically deal with a small number of lines of text, but OmniOutliner for iPad will likely start running into this as people put larger notes into it.
Unlike the Cocoa text system, CoreText doesn't have the same level of built-in facilities for performing layout of a smaller ranges of text. So, each time a change is made to the text, the entire CTFrameRef is rebuilt.
CoreText does have facilities for laying out individual lines of text, which we might be able to use for incremental layout, or we could maybe break up our text based on paragraphs and then "stack" up several CTFrameRefs, but none of this work has been done yet.
In your mail you also said,
Quote:
I have found that when the attributed string that is drawn has no
attributes then it's very fast but when it has a number of attributes or one that spans the whole length of the string then the speed dramatically decreases.
|
I find this strange and interesting. I would have thought the performance would be relative to the number of runs (spans with neighbors having different attributes), but maybe CT is doing other work I'm not expecting. Investigating the difference in the Instruments data from a no-attributes case to all-the-same-attributes case might help speed up some cases.