That was the key! Performance is good again. Thanks very much for the tip. Julian
On 2011-02-01, at 10:26 AM, David Duncan wrote: > 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
