OUIEditableFrame performance issues
 

I am seeing some performance issues with OUIEditableFrame when it is run on the original iPad.

When there is a fair amount of text in the frame say 180 lines, typing/input lags greatly behind and one tap on a key using takes 1-2 seconds. This also considering there is nothing in any of the delegate methods.

Using instruments with the simulator I was able to narrow down the problem and find out what was taking so much time. Turns out it's because the frame is redrawn with every key stroke, what takes up so much time is calling CTFramesetterCreateWithAttributedString and CTFramesetterCreateFrame.

Have any of you realized this or is there something I'm doing that's caused this?

This can be reproduced when a attribute such as font color is set for the whole text. The performance is badly effected because of the Core Text functions.

Can you reproduce this?

You may (probably do) want to send this in via email if you need a guaranteed response. We've got staff dedicated to email support and we collectively browse the forums as we're able on top of our other duties.

We can't promise that a particular member of any given team will be able to respond to threads on the forums in a timely manner, though, and having shipped an app recently, I'm willing to bet that the folks best equipped to provide an answer don't have a lot of time for the forums at the moment. If you send this along to our [EMAIL="omnisource@omnigroup.com"]support ninjas[/EMAIL], though, we can get you some assistance.

Okay, emailed them! Thanks for the help.

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.
[/QUOTE]

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.

I find that it can handle a fair amount of text with ease as long as it doesn't have a number of attributes added to it.

Because in my app I need to add attributes (and quite a lot, to be honest) I had to find a way around this problem by improving the speed of typing but still allowing the user to see the attributes/colors.

I ended up editing OUIEditableFrame so that it only display's the kCTForegroundColor attributes that the user can see at the time. So while the user is typing, all the other kCTForegroundColor attributes the user can't see aren't drawn. When the user scroll's to a point and stops, the view is redrawn so the user can see the color again.

Even though this works fairly well, I'm stilling having trouble with the font as I can't do the same thing as I did with the color because it offsets the text as the line height changes. The problem with the font is that even though I've added the attribute to the whole of the string it is actually split and added to each range with a pre-existing attribute (in my case the color) and the runs in between them.

Have you been able to reproduce the performance problems?

If you have a sample RTF file that produces the problem the same performance profile in Instruments in the TextEditor example (or a modified version of it), it would be great to send along. I can't promise any time frame for fixing it, but being able to reproduce the same issue is the first step.

Even though this may be an extreme example for general use, this is actually quite common in my app: [URL="http://cl.ly/0p261W412b1s052h2Y3j"]http://cl.ly/0p261W412b1s052h2Y3j[/URL]

I think it probably can be reproduced with a slightly smaller file with a similar amount of attributes but I used that one as I am sure that it has performance issues.