Re: CATransactions having no effect in CALayer draw delegate
Re: CATransactions having no effect in CALayer draw delegate
- Subject: Re: CATransactions having no effect in CALayer draw delegate
- From: Ken Tozier <email@hidden>
- Date: Sun, 19 Jun 2011 17:14:30 -0400
On Jun 19, 2011, at 3:57 PM, Kyle Sluder wrote:
> Core Animation's view of the world ends when it hands you a CGContext
> and says "fill this with bits." It can't animate the contents of a
> CGContext because a CGContext really is just an opaque bit receiver
> and associated drawing state. Even though Core Animation attached the
> context to a bitmap (or bitmap provider) before handing it to you, the
> context and the backing store that you're actually drawing into are a
> black box.
>
> All the animations happen at a higher conceptual level. Layers are
> rotated, translated, scaled, and faded. In the case of an implicit
> crossfade because of changing a layer's contents property, what CA is
> actually doing is animating two images that it has previously asked
> you to fill by asking the layer to -drawInContext: twice: once into
> the "old" backing store, and once into the "new" backing store.
Nice and clear. Thanks
>
> As I described above, none of this animation is actually happening
> because of any drawing you're doing in -drawInContext:. Maybe you're
> seeing a crossfade?
I'm seeing a clear evolution from a square corner box to a round corner box and the obvious movement of an image clipped to my generated path. It only takes about 1/2 to 1 second, but looks really silly. Basically the whole point of creating my custom CALayer was to allow for custom layer "bezels" (defined by CGPathRefs) that optionally crop the layer contents to the path, not just round corner boxes.
>
> You're setting the contents property of the layer. So returning nil
> from -actionForKey: should do the trick. I just found this post by
> Matt Neuburg that might explain why you're having trouble:
> http://www.cocoabuilder.com/archive/cocoa/293161-calayer-instant-content-update.html
>
> Basically, the sentinel value that tells Core Animation to stop
> looking for an action to apply to a property change is NOT nil, as
> implied by the documentation and David Duncan's post. Rather, it is
> NSNull. "nil" means "I don't have an answer for you; consult someone
> else," which can be the layer _or_ the default set of implicit
> actions! Rather, try returning [NSNull null] from your -actionForKey:
> override.
I read the link and tried both of the following:
- (id) actionForKey:(NSString *) inKey
{
if ([inKey isEqualToString: @"contents"])
return [NSNull null];
return [super actionForKey: inKey];
}
Produced the error:
-[NSNull runActionForKey:object:arguments:]: unrecognized selector sent to instance 0x7fff701d5fa0
While doing this in my subclass's init method didn't appear to do anything. Class behaved exactly the same as before
self.actions = [NSDictionary dictionaryWithObject:[NSNull null] forKey:@"contents"];
Thanks again for the reply it cleared some things up. At this point though, it's probably a good time to put CALayers aside, at least for now. The inability to simply set the shape of the layer and turn off the blasted animations, when needed, is a deal breaker for me. Not sure why Apple made it so squirrely, but really, the entire point of my subclass was to make it possible to do something like the following.
CGPathRef bezelPath = <some arbitrary path>
layer.bezelAnimationStop;
layer.bezelPath = bezelPath;
layer.bezelAnimationStart;
I saw mention of something called "CAShapeLayer" in the 10.6 release notes. Maybe I'll give that a shot when my patience returns.
Thanks again
-Ken
_______________________________________________
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