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: Clark Cox <email@hidden>
- Date: Thu, 6 Nov 2003 08:05:37 -0500
On Nov 06, 2003, at 07:22, Leon McNeill wrote:
>
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.
The order in which sibling views are drawn is completely undefined.
You have no way of knowing which of two overlapping views will be drawn
first, and which will be drawn second.
--
Clark S. Cox III
email@hidden
http://homepage.mac.com/clarkcox3/blog/B1196589870/index.html
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.