I don't think it has anything to do with wrapping. AFAICT, layout is complete before the delay begins. I think this is a bug that you need to report. Maybe Doug or Aki can chime in with a solution.
Here are some things that I found: 1. The problem is indeed the hyphen characters. Replace all the - with + or _ and everything works fine. 2. The NSTypesetter method -endParagraph, and the NSLayoutManager delegate method textContainer:didCompleteLayout:.... both fire quickly, as they should. That's why I think layout is already over by the time the delay kicks in. I don't know why -insertText: causes a call to -doubleClickAtIndex: after the insertion is complete, or why doubleClickAtIndex: takes so long to run. If you in fact double-click anywhere in the document, it runs instantly. 3. My app, Pagehand, handles the test file just fine. I've heavily subclassed all the components of the text system and I cannot tell what is fixing the problem. 4. As a workaround, could you use underscore characters instead of hyphens? I tried using en dash and got the same result as hyphens. 5. May I suggest that it might not be meaningful to present 70 thousand characters, comprising only ACTG and -, in one scrolling text view? Mightn't you present only a snippet at a time, rather than the entire sequence? Just a thought. Hope this helps. -Ross On Jul 13, 2010, at 3:24 PM, David Swofford wrote: > On Jul 13, 2010, at 2:38 PM, Ross Carter wrote: > >> Could you post a test file somewhere? I just tried creating 187 pages of >> repeating ACCGACTACCGACT in TextEdit and it worked fine. > > > Ah... I see a difference, and it's very relevant. My example has a lot of > hyphen characters in it (FWIW these represent gaps in a sequence alignment > and are typically common in these kinds of files). Your example was all > letters. When I substitute all of the gaps in my example to letters, > TextEdit no longer has this slowdown. It never occurred to me that this > would matter. > > I'm guessing that it has something to do with line/word wrapping, and will > explore further. > > Dave > > > On Jul 13, 2010, at 2:38 PM, Ross Carter wrote: > >> On Jul 12, 2010, at 6:01 PM, David Swofford wrote: >> >>> I'm beginning the conversion of a scientific app from Carbon to Cocoa, and >>> have run into a problem with NSTextView. FWIW, I have it embedded in an >>> NSScrollView that is in turn included as an HICocoaView in a Carbon window >>> (but I don't think this is relevant to my problem). It works, but I've run >>> into a glitch that I can't figure out how to solve. In some cases, I need >>> to be able to edit files containing DNA sequences that look like this: >>> >>> sequence-name-1 ACCGACTACCGACT... >>> sequence-name-2 GACCACTGACCACT... >>> >>> The number of characters in the sequences may run into the tens of >>> thousands, with no spaces or other word breaks. >>> >>> If a file like this is opened in TextEdit (or my program, or Smultron, or >>> TeXShop, or apparently any other NSTextView-based editor with the exception >>> of SubEthaEdit) and I try to insert a non-space character into the middle >>> of the DNA sequence, a painfully long pause (e.g., 30 sec) ensues (with a >>> spinning cursor) before the character appears on the screen and the app >>> becomes responsive again. Inserting the character into sequence name or >>> the intervening whitespace works normally, as does inserting a space >>> character. >>> >>> Spin Control indicates that all of this time is being spent in >>> doubleClickAtIndex (called from NSTextView >>> insertText:replacementRange:_markTextEditedForRange). I can't figure out >>> why the typing of a character causes doubleClickAtIndex to be called, but I >>> wouldn't care if I could just get my editor to stop going AWOL. It does >>> seem like typing a character triggers some kind of word-boundary >>> recalculation that is horribly expensive if the "word" is thousands of >>> characters long. >>> >>> I've tried every NSTextView setting I can think of, and that's when I >>> started looking at other editors to see if they had the same problem as I >>> was having, and they did (except for SubEthaEdit). >>> >>> Is there anything obvious that I might be doing wrong? The fact that the >>> same problem happens in TextEdit as well as several other editors suggests >>> that it's a general problem, but the observation that SubEthaEdit *doesn't* >>> have this problem indicates that there is something I could do to fix it--I >>> just don't know what. >>> >>> Any ideas? I'm really frustrated by this. >> >> Could you post a test file somewhere? I just tried creating 187 pages of >> repeating ACCGACTACCGACT in TextEdit and it worked fine. >> > > -- > David L. Swofford david.swoff...@duke.edu > > Center for Evolutionary Genomics > Institute for Genome Sciences & Policy > Box 90338 > Duke University > Durham, NC 27708 USA > > National Evolutionary Synthesis Center (NESCent) > Suite A200 > 2024 W. Main Street > Durham, NC 27705 USA > > (919)613-7458 (Duke) > (919)668-4591 (Nescent) > > _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
