Re: Understanding layer-backed views
Re: Understanding layer-backed views
- Subject: Re: Understanding layer-backed views
- From: Michael Crawford <email@hidden>
- Date: Tue, 19 Jul 2011 23:59:04 -0400
Well, I suppose I could make sure the window's contentView is not layer backed and then put all of the content that used to be in that view into a new layer-backed view and then add the new layer-backed view as a subview of the contentView.
Next, I create my layer-hosting view and add it to the contentView as a subview, making it a peer of the layer-backed view.
Is that what you mean by restructuring the view hierarchy?
-Michael
On Jul 19, 2011, at 23:44, Scott Anguish <email@hidden> wrote:
>
> On Jul 19, 2011, at 12:27 PM, Michael Crawford wrote:
>
>> Graham; Scott,
>>
>> I have a follow-up question on this topic, if you don't mind. Do either of you have a recommendation on the idea of adding a layer-hosting view as a subview of a layer-backed view?
>
> Yes. You shouldn’t.
>
> When you turn on layer-backing for a view, you turn it on for the entire subview hierarchy. So none of those layers are your’s to mess with. Typically the way around this is to restructure the view hierarchy some.
>
>
>> I'm thinking of adding a virtual keyboard to an existing app that is layer-backed. I would like this VK view to have all the benefits that NSView brings including event handling without all of the heavy-weight of multiple subviews for the keyboard mechanics.
>>
>> Can I mix these?
>>
>> (Please reply to the thread for everyone's benefit.)
>>
>> -Michael
>>
>> On Jun 22, 2011, at 3:02 AM, Scott Anguish wrote:
>>
>>>> Yep, I'm aware of the setWantsLayer/setLayer order making a difference.
>>>>
>>>> In my case I want a layer-hosting view, not a layer-backed view.
>>>>
>>>> However, my question isn't really about that, but about what is done when you check the box next to the layer in Interface Builder, in the 'setWantsLayer' panel. Does this provide layer backing or layer hosting? My thoughts were that is provides layer hosting, but I'm not 100% sure. Proceeding on the basis that this is the case, it seems to work.
>>>>
>>>
>>> layer-backed.
>>>
>>>
>>>
>>>
>>>>
>>>>> Again this is not in line with my expectations, which is that the frame of a sublayer is expressed in the coordinate system of its superlayer, not the underlying window.
>>>>
>>>> I found the cause of this issue, which was that in my layer delegate, I was not saving, setting and restoring the context passed to drawLayer:inContext:. I was assuming that the context was set, but having found a code snippet in the docs that indicated it wasn't, I added these calls and my graphics are drawing in the right place now.
>>>>
>>>
>>> great!_______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden