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: Leon McNeill <email@hidden>
- Date: Thu, 6 Nov 2003 12:22:28 +0000
On 6 Nov 2003, at 11:09, Alastair Houghton wrote:
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).
"You aren't supposed to overlap sibling views" is a bit strong of a
statement, isn't it? According to the documentation, it's simply "not
recommended", and in my case nesting a view that's to be drawn on top
of another made no difference to performance according to my tests, and
would merely serve to greatly complicate my layout process. Indeed,
[NSView addSubview:positioned:relativeTo:]'s documentation seems to
indicate that there's nothing wrong with overlapping sibling views. I
would definitely like to hear some concrete statements about how I'll
suffer by using overlapping sibling NSViews.
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.
Loads of the time is being spent in NSView's private machinations,
determining what NSViews it's going to ask to draw, locking and
unlocking focus, retaining and releasing objects, and sending messages
around. Relatively little time is actually spent in my code
(drawRect). This is using Sampler while simply scrolling through my
NSScrollView's contents; I'm not telling anything to display or
setNeedsDisplay (or invoking drawRect myself) anywhere in my code.
I'm definitely inclined to agree with you, that my best hope lies in
eliminating as many NSViews as I can. It's just disappointing that
there seems to be so much overhead in NSViews.
--
Leon McNeill email@hidden www.lairware.com
_______________________________________________
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.