In case anyone is interested... I filed a bug. In the meantime, I am able to work around the problem by subclassing NSTextStorage and overriding doubleClickAtIndex: (a suggestion by Doug Davidson). I didn't have a clue how to write the primitive methods required for subclassing NSTextStorage, but a sample was kindly provided by Ross Carter, who even took a guess at the override, which worked perfectly!
Basically, this works by allocating our own NSMutableAttributedString object in the subclass init method and using this object in the implementations of the required primitives, mostly just calling the corresponding NSMutableAttributedString methods. The same thing is done in the doubleClickAtIndex: override. I think Aki is saying that NSTextView is doing some performance optimization that seems to go horribly wrong in my example. I was curious if overriding this would degrade performance, but I don't see a noticeable difference between the original code and the one that uses the override (on an example not affected by the bug). Dave On Jul 13, 2010, at 8:18 PM, Aki Inoue wrote: > This is indeed an issue with the text system (trying to pre-heat the inserted > text range for various text checking tasks). > Please file a bug. > >> 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. > These suggestions should be able to help implementing workarounds for the > issue. > > Thanks !! > > Aki > > On 2010/07/13, at 16:34, Ross Carter wrote: > >> 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 _______________________________________________ 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
