Flipboard/FLAnimatedImage — pull request #43 by nolanw (2014-10-23 20:45:02+00:00)
Title: Avoiding costly CGImage creation during FLAnimatedImage initialization?

Hello! I'm curious about some behaviour in the initializer of FLAnimatedImage. At the moment it's [line 203 of FLAnimatedImage.m](https://github.com/Flipboard/FLAnimatedImage/blob/master/FLAnimatedImageDemo/FLAnimatedImage/FLAnimatedImage.m#L203), wherein a CGImage is created for each frame in the CGImageSource.

I'm guessing the idea here was to drop frames that aren't going to display anyway, and adjusting the timings appropriately. That makes sense to me. Decoding the first (working) frame for use as a "poster image" and for buffer size calculations also makes sense to me.

However, CGImageSourceCreateImageAtIndex is a costly operation, and it would be excellent to avoid it in the cases where the created CGImage isn't actually used. Not only does it feel wasteful (as the frames will be decoded once again during playback), it makes FLAnimatedImage initialization much slower than maybe it needs to be. If my guesses above are correct, I think we can speed things up tremendously.

Are my guesses here correct? I'm happy to poke around and maybe open a pull request, but I want to make sure I'm not missing anything.