Unclear on NSView's isOpaque concept (and optimization in general)
Unclear on NSView's isOpaque concept (and optimization in general)
- Subject: Unclear on NSView's isOpaque concept (and optimization in general)
- From: Leon McNeill <email@hidden>
- Date: Thu, 6 Nov 2003 10:26:07 +0000
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. 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"?
--
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.