On Apr 30, 2013, at 18:37 , Gideon King wrote:
> How did you test it? Did you sort the views at all, or just leave them in the
> order they were instantiated?
My hierarchy is very simple. The content view contains a single view (which
layer-backed in order to use a background color), and that
How did you test it? Did you sort the views at all, or just leave them in the
order they were instantiated? Did you try Sean's workaround?
Regards
Gideon
On 01/05/2013, at 4:39 AM, Quincey Morris
wrote:
>
> Nope. I just tried it again, setting the layer-backed checkboxes all the way
>
On Apr 30, 2013, at 08:55 , Mike Abdullah wrote:
> On 30 Apr 2013, at 16:53, Gideon King wrote:
>
>> So it sounds as if as long as I have all my views in the entire hierarchy
>> layer backed, my sibling views should always draw in order.
>
> Yup. Bear in mind WebViews don't support being lay
On Tue, 30 Apr 2013 01:30:00 -0700, Quincey Morris said:
>On Apr 30, 2013, at 00:39 , Gideon King wrote:
>
>> My scenario is a whole lot of sibling, potentially translucent,
>overlapping, layer backed views.
>
>I've never seen any evidence that sibling *NSView*s draw in the wrong
>order since 10.
On 30 Apr 2013, at 16:53, Gideon King wrote:
> So it sounds as if as long as I have all my views in the entire hierarchy
> layer backed, my sibling views should always draw in order.
Yup. Bear in mind WebViews don't support being layer-backed (still!), which can
throw a spanner in the works.
So it sounds as if as long as I have all my views in the entire hierarchy layer
backed, my sibling views should always draw in order.
This makes me happy :) … and the documentation wrong :( - I'll report that.
Regards
Gideon
___
Cocoa-dev maili
On Tuesday, 30. April 2013 at 10:42, Mike Abdullah wrote:
> Layer-backed views always *appear* above non-layer-backed views. Effectively,
> all non-layer-backed views get rendered into a single layer that makes up the
> entire window.
Thanks, didn't know this. Never needed layer backed view unti
On 30 Apr 2013, at 09:38, Robert Vojta wrote:
>> I've never seen any evidence that sibling *NSView*s draw in the wrong order
>> since 10.5. I believe that 'drawRect:' is correctly called in the
>> back-to-front order of the sibling arrangement in the parent view.
>>
>> However, I *have* seen
> I've never seen any evidence that sibling *NSView*s draw in the wrong order
> since 10.5. I believe that 'drawRect:' is correctly called in the
> back-to-front order of the sibling arrangement in the parent view.
>
> However, I *have* seen firsthand, in the last few weeks, that the layers of
On Apr 30, 2013, at 00:39 , Gideon King wrote:
> My scenario is a whole lot of sibling, potentially translucent, overlapping,
> layer backed views.
I've never seen any evidence that sibling *NSView*s draw in the wrong order
since 10.5. I believe that 'drawRect:' is correctly called in the back
I had to design my whole view system to work around the problems with
> overlapping sibling views not being guaranteed to be drawn in a specific
> order, but today I came across some posts that suggested that this was no
> longer the case.
>
> In the current 10.8 documentation it
Hi, I had to design my whole view system to work around the problems with
overlapping sibling views not being guaranteed to be drawn in a specific order,
but today I came across some posts that suggested that this was no longer the
case.
In the current 10.8 documentation it still says: "
10.5.
I can't find anything in the documentation (or even release notes)
that describes that/how overlapping views are supported. Why isn't
this documented? Can we rely on overlapping sibling views working
now and in the future? Are there any caveats we should be aware of?
I be
z-ordering was documented as guaranteed
before.
It was. I have a Tiger system with the old docs and those quotes
were present -- and coexisted with the warnings that overlapping
sibling views didn't guarantee correct clipping, invalidation, or
drawing. And so I took that documentatio
On Aug 28, 2008, at 2:40 PM, Corbin Dunn wrote:
Please do log bugs requesting the documentation to be enhanced.
Overlapping views do work in Leopard+, with or without layers.
However, a sibling layered view will always be on top of a sibling
non-layered view.
I will do so, as well as a bug
On Aug 28, 2008, at 5:09 PM, Ken Thomases wrote:
On Aug 28, 2008, at 3:28 PM, Nathan Vander Wilt wrote:
According to two list postings (http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01760.html
, http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01764.html)
both by Apple employees
ntation (or even release notes)
that describes that/how overlapping views are supported. Why isn't
this documented? Can we rely on overlapping sibling views working
now and in the future? Are there any caveats we should be aware of?
I believe that Apple relaxed the rules to allow CoreAnimat
s documented? Can we rely on overlapping sibling views working
now and in the future? Are there any caveats we should be aware of?
I'd be interested in knowing that, too.
Especially, I'd be curious to know how such support works when
drawing outside of drawRect: using the lockFocu
at/how overlapping views are supported. Why isn't
this documented? Can we rely on overlapping sibling views working
now and in the future? Are there any caveats we should be aware of?
I believe that Apple relaxed the rules to allow CoreAnimation layers
to work correctly. Whether or non a
w overlapping views are supported. Why isn't
this documented? Can we rely on overlapping sibling views working
now and in the future? Are there any caveats we should be aware of?
Hello,
Please file a couple of bug reports on this:
<http://devel
this documented? Can we rely on overlapping sibling views working now
and in the future? Are there any caveats we should be aware of?
thanks,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comm
21 matches
Mail list logo
