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:24:08 -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.
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 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