Re: NSTextView becomes temporarily unresponsive
Re: NSTextView becomes temporarily unresponsive
- Subject: Re: NSTextView becomes temporarily unresponsive
- From: David Swofford <email@hidden>
- Date: Tue, 13 Jul 2010 15:00:44 -0400
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.
Thanks for your interest! I've put an example at http://www.duke.edu/~dls36/nstextview_problem/
Remember, you have to start typing somewhere in the sequence itself to see the problem that I get with TextEdit (OSX 10.6.4).
If you don't see the unresponsiveness that I see, I'd be *very* interesting in exploring why...
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 email@hidden
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 (email@hidden)
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:
This email sent to email@hidden