On May 17, 2011, at 2:58 PM, Kyle Sluder wrote:
> You could also try using -makeBackingLayer. That's useful if your view
> can be used both programmatically and in a nib.
I wonder if that method works for a layer-hosting view, which is what my view
is -- not a layer-backed view. But even if it
On Tue, May 17, 2011 at 11:35 AM, Bill Cheeseman wrote:
> I agree that the explanation doesn't logically lead to a prohibition on
> creating layers in -initWithFrame:. That's why I initially created them
> there, deferring only the construction of the layer tree to -awakeFromNib.
> But I suffer
On May 17, 2011, at 12:58 PM, David Duncan wrote:
> The basic problem comes about when a view in the nib has wantsLayer=NO, but
> the view itself always wants to be layer backed. If you setWantsLayer:YES
> inside of -initWithFrame:, then by the time you get to -awakeFromNib
> wantsLayer=NO aga
On Tue, May 17, 2011 at 10:21 AM, Keith Duncan wrote:
>
>> The basic problem comes about when a view in the nib has wantsLayer=NO, but
>> the view itself always wants to be layer backed. If you setWantsLayer:YES
>> inside of -initWithFrame:, then by the time you get to -awakeFromNib
>> wantsLay
> The basic problem comes about when a view in the nib has wantsLayer=NO, but
> the view itself always wants to be layer backed. If you setWantsLayer:YES
> inside of -initWithFrame:, then by the time you get to -awakeFromNib
> wantsLayer=NO again
Would there be any issue with overriding -setWa
On May 17, 2011, at 9:49 AM, Bill Cheeseman wrote:
> On May 17, 2011, at 11:33 AM, David Duncan wrote:
>
>> There should be no actual restriction like that however. That said, as you
>> point out, if you have view that supports layers and come from a nib, you
>> often have to duplicate work to
On May 17, 2011, at 11:33 AM, David Duncan wrote:
> There should be no actual restriction like that however. That said, as you
> point out, if you have view that supports layers and come from a nib, you
> often have to duplicate work to allow it to work in both situations.
I'm not sure I foll
On May 17, 2011, at 1:26 AM, Bill Cheeseman wrote:
> Answering my own question: Although it's hard to be sure that a random
> problem is really fixed, it appears that the solution was to stop creating
> Core Animation layers in the view's -initWithFrame: method and instead create
> them in the
On May 16, 2011, at 8:11 AM, Bill Cheeseman wrote:
> When I quit and relaunch the application, the animations sometimes don't run
> for the full specified duration when I hit the hot key. During any given run
> of the application, the animations either work correctly every time I hit the
> hot
On Mon, 16 May 2011 08:11:36 -0400, Bill Cheeseman said:
>My Mac OS X application has an borderless transparent overlay window with a
>layer-hosting view. The view's layers add a bunch of animations in response to
>a hot key. It all works correctly -- sometimes.
>
>What could account for sublaye
My Mac OS X application has an borderless transparent overlay window with a
layer-hosting view. The view's layers add a bunch of animations in response to
a hot key. It all works correctly -- sometimes.
When I quit and relaunch the application, the animations sometimes don't run
for the full sp
11 matches
Mail list logo
