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: WT <email@hidden>
- Date: Sat, 4 Apr 2009 05:13:40 +0200
Thank you, Glenn and David.
In a perfect world, the application would be designed in a way that
completely abstracts how the animations are going to be implemented
but, alas, I'm not that experienced yet, so I am still trying to
ascertain what the best approach to go with is, so I won't have to do
a major retrofitting at the end.
openGL is not an option at the moment, since I have only a cursory
knowledge of it and am not prepared to invest the time needed to learn
it now.
I also have no direct experience with CoreAnimation, but it doesn't
look so difficult and I *am* prepared to invest time on it.
I think the problem can be broken down in two parts:
1) drawing the grid itself in an animated fashion
This is a one-time event.
When the grid is first shown, I'd like to draw the balls in some
interesting pattern, rather than the boring left-to-right along a row,
one row at a time top-to-bottom. This part I have already done by
collecting the grid balls into an array, in the sequence I want, and
then firing a timer that grabs the next item off the array and draws
it in its assigned position on the grid.
Currently, I am using UIImageViews for these grid items, so the timer
callback simply sets their frames and adds them as subviews of the
superview. Alternatively, I could use (cached) UIImages and draw them
in the superview's -drawRect method, in which case the timer callback
would set the correct state (say, the row and column indices of the
next position to draw at and the image to draw there) and then call -
setNeedsDisplay on the superview.
Given that drawing the grid this way happens only once, I think my
current solution is probably good enough, performance-wise.
2) animating each grid ball
Each grid ball itself is animated at all times, going through 9 images
ranging in size from 13x13 to 21x21 pixels. Since there are 2
interlocking grids of 7x7 balls, we're talking about 98 independently
animating entities.
If these entities are UIImageViews (as they are now), then there are
98 subviews and at least 98 threads running (the docs say that
UIImageView animates its images in a separate thread). 98 subviews
aren't going to be a problem, I think, because I'm not moving them nor
changing their relative positions in the view hierarchy. I am,
however, concerned with 98 threads.
I imagine I could still have UIImageViews - but a single thread - by
firing a timer that *sets* the current image of each UIImageView,
rather than have them animate independently.
Alternatively, I could forgo the UIImageView idea altogether and have
a timer that calls -setNeedsDisplay, just as before. I don't see much
of an advantage here compared to the alternative immediately above.
I could also use Core Animation layers as suggested by Glenn. Another
option is what David suggested, to use a texture atlas. I understand
how texture atlases work and it sounds like a great idea. Either way,
I can't evaluate off-hand what trade-offs are involved, since I'm not
familiar with Core Animation.
I should point out that there will be 2 other entities moving on the
screen, on top of the grid, and these other entities are also
independently animated. Finally, there are 6 other entities elsewhere
on the screen (not overlapping the grid) that *never* move, but also
animate independently.
A movie is worth a million words, so here's the gist of it (with
temporary art work and other things missing):
http://www.restlessbrain.com/iPhone/AnimTest.mov
Given these constraints, I'd be grateful for a recommendation on what
approach is likely to be the most efficient. Yes, I know I should
profile the application to answer that question, but the reality is
that I cannot afford right now to spend the time needed to implement
several different approaches, especially when I'm not sufficiently
familiar with them all to be able to do it quickly and reasonably bug-
free.
Thank you all in advance.
Wagner
_______________________________________________
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