Home/ Questions/Q 213903
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T18:19:22+00:00

in my (puzzle) game the pieces are drawn on-screen using a CALayer for each

  • 0

in my (puzzle) game the pieces are drawn on-screen using a CALayer for each piece. There are 48 pieces (in an 8×6 grid) with each piece being 48×48 pixels. I’m not sure if this is just too many layers, but if this isn’t the best solution I don’t know what is, because redrawing the whole display using Quartz2D every frame doesn’t seem like it would be any faster.

Anyway, the images for the pieces come from one big PNG file that has 24 frames of animation for 10 different states (so measures 1152 x 480 pixels) and the animation is done by setting the contentsRect property of each CALayer as I move it.

This actually seems to work pretty well with up to 7 pieces tracking a touch point in the window, but the weird thing is that when I initially start moving the pieces, for the first 0.5 a second or so, it’s very jerky like the CPU is doing something else, but after that it’ll track and update the screen at 40+ FPS (according to Instruments).

So does anyone have any ideas what could account for that initial jerkiness?

The only theory I could come up with is it’s decompressing bits of the PNG file into a temporary location and then discarding them after the animation has stopped, in which case is there a way to stop Core Animation doing that?

I could obviously split the PNG file up into 10 pieces, but I’m not convinced that would help as they’d all (potentially) still need to be in memory at once.

EDIT: OK, as described in the comment to the first answer, I’ve split the image up into ten pieces that are now 576 x 96, so as to fit in with the constraints of the hardware. It’s still not as smooth as it should be though, so I’ve put a bounty on this.

EDIT2: I’ve linked one of the images below. Essentially the user’s touch is tracked, the offset from the start of the tracking is calculated (they can one move horizontal or vertical and only one place at a time). Then one of the images is selected as the content of the layer (depending on what type of piece it is and whether it’s moving horizontally or vertically). Then the contentsRect property is set to chose one 48×48 frame from the larger image with something like this:-

layer.position = newPos;
layer.contents = (id)BallImg[imgNum];
layer.contentsRect = CGRectMake((1.0/12.0)*(float)(frame % 12), 
                                0.5 * (float)(frame / 12), 
                                1.0/12.0, 0.5);

btw. My theory about it decompressing the source image a-fresh each time wasn’t right. I wrote some code to copy the raw pixels from the decoded PNG file into a fresh CGImage when the app loads and it didn’t make any difference.

Next thing I’ll try is copying each frame into a separate CGImage which will get rid of the ugly contentsRect calculation at least.

Sample image

EDIT3: Further back-to-basics investigation points to this being a problem with touch tracking and not a problem with Core Animation at all. I found a basic sample app that tracks touches and commented out the code that actually causes the screen to redraw and the NSLog() shows the exactly the same problem I’ve been experiencing: A long-ish delay between the touchesBegin and first touchesMoved events.

2009-06-05 01:22:37.209 TouchDemo[234:207] Begin Touch ID 0 Tracking with image 2
2009-06-05 01:22:37.432 TouchDemo[234:207] Touch ID 0 Tracking with image 2
2009-06-05 01:22:37.448 TouchDemo[234:207] Touch ID 0 Tracking with image 2
2009-06-05 01:22:37.464 TouchDemo[234:207] Touch ID 0 Tracking with image 2
2009-06-05 01:22:37.480 TouchDemo[234:207] Touch ID 0 Tracking with image 2

Typical gap between touchesMoved events is 20ms. The gap between the touchesBegin and first touchesMoved is ten times that. And that’s with no computation or screen updating at all, just the NSLog call. Sigh. I guess I’ll open this up a separate question.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I don’t think it’s a memory issue; I’m thinking that it has to do with the inefficiency of having that large of an image in terms of Core Animation.

    Core Animation can’t use it natively, as it exceeds the maximum texture size on the GPU (1024×1024). I would break it up some; individual images might give you the best performance, but you’ll have to test to find out.

    IIRC, UIImageView does its animating by setting successive individual images, so if it’s good enough for Apple….

    • 0