Re: Unclear on NSView's isOpaque concept (and optimization in general)
Re: Unclear on NSView's isOpaque concept (and optimization in general)
- Subject: Re: Unclear on NSView's isOpaque concept (and optimization in general)
- From: Alastair Houghton <email@hidden>
- Date: Thu, 6 Nov 2003 11:09:50 +0000
On 6 Nov 2003, at 10:26, Leon McNeill wrote:
Pun groans aside, I guess I don't completely 'get' what isOpaque is
supposed to be doing. My NSView subclasses that return YES for
isOpaque do not seem to be inhibiting the drawing of views completely
obscured by them. Could someone point out some sample code that
illustrates the difference between returning isOpaque YES versus NO?
None of my simple testing indicates a difference.
To speak more broadly, the presence of large numbers of NSViews in a
given window seems to drag down the response and update time of
anything else in the window, regardless of whether the views are
visible, clipped out, behind an isOpaque view, or in a completely
separate scroll view.
When you say "behind an isOpaque view", you do know that you aren't
supposed to overlap sibling views in Cocoa? If a view is "on top" of
another view, it should be a child of that view. AFAIK -isOpaque is
just used to decide when to stop traversing the view hierarchy
(basically, if a view returns -isOpaque, and all updates were within
that view's frame, then there's no need to examine the parent view).
I understand that there is potentially a large amount of overhead
involved in every NSView -- autoresizing subviews, notification
posting, drag receiving, and of course everything that's inherited
from NSResponder -- but simply scrolling through a couple of hundred
NSViews gets quite chunky even if the views aren't drawing anything
complicated (or indeed, anything at all).
Does anyone have any pointers on how I might optimize my NSViews --
aside from the obvious "don't use so many NSViews"?
The obvious solution is probably the best, in this case. Otherwise,
try profiling your application and see where all of the time is being
spent.
Kind regards,
Alastair.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.