Re: Using UIImageView for animations
Re: Using UIImageView for animations
- Subject: Re: Using UIImageView for animations
- From: "Glenn Bloom" <email@hidden>
- Date: Mon, 12 Jan 2009 23:10:17 -0500
David,
Thanks for your insight. Just have a couple of follow up questions:
- When I animate a set of PNG's rather than JPEG's (again using
UIImageView's animationImages property), I am thinking I don't need to
think about compression (or Apple optimization)? Is it then appropriate to
think of the total memory to be consumed simply as an aggregate of the total
bytes for all the images?
- Am I correct in thinking that for loading a short-running animation, I
should generally use the initWithContentsOfFile method of UIImage instead of
imageNamed because imageNamed caches the data into memory?
- I had thought there was a way to use Instruments to assess if a
UIImageView animation was skipping frames. Now, I'm not so sure. Any
particular way to test if such an animation is skipping or not displaying
frames?
thanks again,
Glenn
On Mon, Jan 12, 2009 at 12:40 PM, David Duncan <email@hidden>wrote:
> On Jan 10, 2009, at 12:01 PM, Alex Strand wrote:
>
> I'm taking a set of 10-20 jpegs that I'd like to animate. I started out
>> just using a UIImageView using setAnimationImages: and everything worked
>> fantastically in the simulator but testing it on my device basically makes
>> it slow to the point where it is unresponsive. I've done some searching
>> around and some people indicate that they are able to use CALayers to get
>> this same effect but before going down that path I thought I would ask you
>> folks.
>>
>
>
> How well this will work is highly dependent on how large each of these
> images are. Assuming that they are full screen in size (since you mention a
> performance issue) then 1 JPEG will decompress to about 600K, and thus 10-20
> to between 6-12MB. This is a LOT of memory, and you are likely to see many
> different issues (although performance in this case would likely be due to
> having a number of other views or cached images also loaded).
>
> UIImageView basically does the same thing that you would do with a CALayer
> to animate images in most cases anyway. There are alternative means by which
> you can animate an image via a CALayer, but it comes with other restrictions
> (primarily on image size).
>
> On Jan 11, 2009, at 9:04 AM, Glenn Bloom wrote:
>
> I don't think I see this issue in my own code using UIImageView with a
>> like number of JPEG's. How large are yours? For a variety of reasons, I
>> have found that optimizing mine as 150KB or less each is acceptable for 480
>> * 320 pixel images.
>>
>
> It sounds like you are considering file size. File size is irrelevant in
> terms of graphical performance of compressed image formats, as the images
> will need to be (at least partially) decompressed for usage. In the case of
> a fullscreen JPEG image, it will be fully decompressed into a 32-bit per
> pixel format, which means the actual memory usage is 320x480x4=600KB. If you
> are seeing acceptable performance, then you are likely not pushing up
> against the maximum amount of memory the graphics subsystem can reference
> (24MB) and thus not seeing the performance cliff that going past that limit
> causes.
>
> On Jan 11, 2009, at 10:06 AM, Robert Marini wrote:
>
> As Glenn indicated, this is largely a factor of the size of the images.
>> Layers are considerably lighter weight than Views (with the associated
>> functionality loss).
>>
>
> Views are based on Layers, so in that respect a view is heavier than a
> layer, but in general usage terms it is not so much so that I would consider
> using a layer over a view if I needed any feature that a view might offer.
>
> Of course, doing what you want to do - depending on the animation involved
>> - might simply be having two image views and animating between then while
>> changing their image backings (UIImageView is the presentation layer for a
>> UIImage and so it is generally most appropriate to have only the max number
>> of UIImageViews that you need to display at once in memory).
>>
>
> This might be an acceptable solution, although to control memory you should
> not use +imageNamed: to load these images (and instead use
> imageWithContentsOfFile:) as you would likely run into the exact same
> performance problem if you did. This may also end up with other performance
> issues unfortunately.
> --
> David Duncan
> Apple DTS Animation and Printing
>
>
_______________________________________________
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