[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: animation performance Brother Josef Fri Aug 24 12:04:43 2007

On Aug 23, 2007, at 8:31 AM, Scott Thompson wrote:

On Aug 22, 2007, at 8:03 PM, Brother Josef wrote:
   provider := CGDataProviderCreateWithURL(url);
outImage := CGImageCreateWithPNGDataProvider(provider, nil, 0, kCGRenderingIntentDefault);

   cellImage := CGImageCreateWithImageInRect(tableImage, cellRect);

Hmm... I would be very concerned about creating the image from a PNG data provider. When you do this, the system will decompress the image every time you draw it. I'm not sure about the behavior with a sub-image created from an PNG image, but if it's decompressing the PNG every time you have to redraw a different sub- image that would be Very Bad(tm). You could probably see this in Shark.

that's interesting information, I did not know that PNG. I don't have Shark, never came built on my system or with my latest Xcode tools. i'll try to download it elsewhere.

thanks again, that's prime suspect number 1. I'll pull the PNG's tonight and see what happens. 10.4 and up at this point.

Are you trying to be Tiger only, or do you need to run on older systems?

If you are Tiger only, you might change your code to use CGImageSource and add the kCGImageSourceShouldCache flag so that the PNG data will be decompressed once and reused subsequently.

If you are not able to support Tiger and later, then you might try drawing your PNG into a big CGBitmapContext, create your mosaic image from that and your sub-images from the mosaic image. That way the overhead of decompressing the PNG Is incurred once (when you draw the mosaic).

Have you considered using CGLayers instead of CGImages? If I were creating a sprite engine, I might consider creating separate layers for each frame of the sprite and then drawing the appropriate layer when the sprite needs to drawn.

I used layers where i was caching collections of images but i don't quite understand how they would be useful with each sprite. I'm thinking this is a caching issue happening from CG to video memory.

I'm curious why you might think it is an issue of cacheing information between CG and VRAM. Given the new information you've provided, I begin to suspect it's more a question of caching the result of unpacking the PNG data, but that's based on pure speculation without some quality time with the performance tools.

I'm just making poor guesses, i don't understand much about this area. If i knew more about the graphic format i was using i would suspect that more.

If it is a cacheing image between CG and video memory then I would expect Layers to be your friend. CG (at a high level) and the OpenGL system of Mac OS X (at a low level) is very clever about VRAM resource allocation and cacheing. CGLayers are a prime high level interface for taking advantage of this cleverness. The whole point behind a CGLayer is that it is going to provide you with a backing store that is optimized for fast transfer to a particular context. In this case, you could create a separate layer for each frame of your sprite (or potentially a separate layer for each mosaic and then just use clipping rectangles/paths to get at individual sprite images). The operating system will handle efficient swapping of your layer image to the VRAM when necessary and unloading of that VRAM when it is no longer necessary.

that is faster then pre-loading all the bitmaps into memory? Is CG accessing a CGLayer faster than RAM? So, in otherwords all graphics should be loaded into one massive CGLayer and clipped to draw from the layer? Currently I'm just using them for static sprite layers, which works very well.



Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list      ([EMAIL PROTECTED])
Help/Unsubscribe/Update your Subscription:

This email sent to [EMAIL PROTECTED]