Re: NSTextView becomes temporarily unresponsive
Re: NSTextView becomes temporarily unresponsive
- Subject: Re: NSTextView becomes temporarily unresponsive
- From: Ross Carter <email@hidden>
- Date: Tue, 13 Jul 2010 19:34:27 -0400
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 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