Re: -[CALayer setContents:] slower in iOS 4.2?
Re: -[CALayer setContents:] slower in iOS 4.2?
- Subject: Re: -[CALayer setContents:] slower in iOS 4.2?
- From: David Duncan <email@hidden>
- Date: Tue, 1 Feb 2011 09:26:57 -0800
On Jan 31, 2011, at 4:12 PM, Julian Wood wrote:
> We grab the appropriate image portion from the spriteAtlas using CGImageCreateWithImageInRect(CGImageRef image, CGRect rect). In general, we haven't been hitting the memory limit on the device with this approach, and when it does, it recovers nicely.
This will almost always invoke a copy rather than using the original image atlas. If you want to use an atlas with Core Animation, you should use the contentsRect property to extract the subimage (it is in a unit coordinate system, just like texture coordinates are) and use the entire image as the layer's contents.
> Basically the sprites are very laggy and the animation is choppy, until resources have fully loaded (it can take from 1s to 30s to fully settle down). The culprit would appear to be -[CALayer setContents:], which can take on the order of 0.3s-0.8s, the first time the image is used. The problem is then exacerbated as we re-enter the gameloop, with resources not in place.
This is likely the copy-hit due to CGImageCreateWithImageInRect. On iOS 3.2 (depending on how you loaded the image) the image may already have been decoded to an in-memory cache, and so the copy was fast. On iOS 4.2 the image may never be decoded to an in-memory cache, and as such you are taking the decode hit for every subimage you request.
Using the contentsRect property should get you both the loading behavior and performance that you desire.
> One final note - my CADisplayLink timer does not seem very reliable - ie, I get between 2 and 200 fps, when I should only ever get 15fps, assuming it is tied directly to hardware. Perhaps because it is also on the main runloop, it is suffering as well? While these anomalies are rare, they occur exactly when trying to load a new sprite atlas image. It seems like this alone could be causing the problem. I'm looking now at running it on another runloop or thread. NSTimer doesn't change anything appreciably, either.
This is a plausible explanation, although it probably couldn't hurt to file a bug with something that demonstrates the behavior.
--
David Duncan
_______________________________________________
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