Re: Using UIImageView for animations
Re: Using UIImageView for animations
- Subject: Re: Using UIImageView for animations
- From: David Duncan <email@hidden>
- Date: Mon, 12 Jan 2009 09:40:10 -0800
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