• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSTextView HICocoaView performance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSTextView HICocoaView performance


  • Subject: Re: NSTextView HICocoaView performance
  • From: Ryan Joseph <email@hidden>
  • Date: Thu, 9 Apr 2009 22:42:58 +0700


On Apr 9, 2009, at 10:22 PM, Marcel Weiher wrote:


On Apr 9, 2009, at 7:51 , Ryan Joseph wrote:
On Apr 9, 2009, at 9:42 PM, Marcel Weiher wrote:
On Apr 9, 2009, at 1:06 , Ryan Joseph wrote:

[NSTextView in  HICocoaView performance problems]

[requests for more information]

I have used NSTextView in Cocoa windows without the HICocoaView and there is no problem so I assume this is a HICocoaView issue.

Sounds like a reasonable assumption...which 30 seconds with Shark would allow you to confirm or refute: launch Shark, launch your app, <alt><esc> do operation <alt><esc>.

I will test first thing tomorrow.


Is the TextEdit example Carbon?

No.

No, I have not done any performance tests because I don't have any control over the API's, NSScrollView/NSTextView and can not make optimizations. At around 1000+ lines if you insert/delete lines at the top (i.e. low offsets) the problem is there.

Hmm...that's odd and makes me wonder wether HICocooaView is the right suspect: the (layout) computations that are data-dependent shouldn't really have any interactions with the container that the text-view is in, and certainly shouldn't have a need for them. Maybe there is something else going on?

Who knows what the interaction between the Cocoa view and Carbon view is doing. I'm sorry for not giving much information but I was hoping that first anyone could confirm NSTextView works with HICocoaView without these issues. My feeling is this is a bug with the bindings between the 2 systems.


I didn't mention the NSScrollView and NSTextView are created programatically but still I don't see how the API would work with the exception of some performance issues. I'll test with shark but any other test would be useful. Maybe asking the Carbon list would be a good idea also. Thanks again.



Marcel


Regards, Josef

_______________________________________________

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


References: 
 >NSTextView HICocoaView performance (From: Ryan Joseph <email@hidden>)
 >Re: NSTextView HICocoaView performance (From: Marcel Weiher <email@hidden>)
 >Re: NSTextView HICocoaView performance (From: Ryan Joseph <email@hidden>)
 >Re: NSTextView HICocoaView performance (From: Marcel Weiher <email@hidden>)

  • Prev by Date: Re: IKImageBrowserView crash
  • Next by Date: Re: Floating window on top of everything
  • Previous by thread: Re: NSTextView HICocoaView performance
  • Next by thread: navigate in and around xib files
  • Index(es):
    • Date
    • Thread