Re: How to animate the drawing of UIImages inside a drawRect: method of a UIView?
Re: How to animate the drawing of UIImages inside a drawRect: method of a UIView?
- Subject: Re: How to animate the drawing of UIImages inside a drawRect: method of a UIView?
- From: glenn andreas <email@hidden>
- Date: Fri, 03 Apr 2009 11:30:54 -0500
On Apr 3, 2009, at 10:15 AM, WT wrote:
I do have a custom UIView for the grid, but it doesn't do much for
now, since I'm currently using the UIImageView instances to do the
heavy lifting.
You are aware that you can pass an array of UIImages to a UIView
and it will animate them at whatever speed you tell it, right?
It's not perfect (it's hard to sync between multiple views unless
you set them all at once), but handles simple things fine. I've
made an "animated GIF" viewer widget using this and it works quite
well...
Yes, I am aware of that. That's how I am doing things right now. I
have 98 UIImageView instances, each associated with an array of up
to 9 UIImage objects. I think it's *very* convenient. I set the
pulsating animation on each UIImageView and I don't have to worry
about it. My original question is one of efficiency, given how many
UIImageViews I have as active subviews at any one time.
You are going to, in general, be hard pressed to get more efficient
than UIImageView. If there were a faster way to draw a UIImage on the
screen, UIImageView would use it (and probably does - it has access to
internal private API caching/drawing details that you don't).
Remember that the built in view classes are designed to be as
efficient as practical (for example, the docs say that it is more
efficient to embed a UILabel subview than to use the built in string
drawing routines)
So it comes down to "can you draw a grid of images faster than a grid
of UIImageViews". Obviously the "move the bits around" drawing part
isn't going to be faster, so is the question becomes one of the
overhead of having a boatload of views drawing vs your single view
drawing. It seems like the answer should be "probably", but you're
going to have to use the performance tools to make sure - it may turn
out that what you gain in by having the single view is lost by loosing
the "knows private APIs" speed.
(There may be other constraints, such as the synchronization of the
animation, that may preclude using the grid of UIImageViews)
There are, however, two techniques that can be taken. The first (and
easiest) is to switch to using CALayers directly (UIViews are built
"on top of" CALayers). Make your view a grid of CALayers (which each
CALayer has an individual image). This obviously involves going a bit
deeper than just using UIImageViews, but it's not too bad. If you
want to get more efficiency without major changes (at the cost of
loosing some of the capabilities that come with having separate views,
such as more complicated hit testing, having to do your own animation,
etc...), this is probably your best bet.
The other (and this will give you the most efficiency) is to switch
over to OpenGL, but obviously this is hard retrofit into an existing
app (not to mention requires being up to speed with OpenGL).
And no matter what, run Shark to see where any performance bottlenecks
actually are! (They may be in code you have no control over)
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium | prime : build, mutate, evolve, animate : the next
generation of fractal art
_______________________________________________
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