|
|
Do too many RTimer aggravate system performance?
| Tue, 2008-02-26 03:20 | |
|
Do too many RTimer aggravate system performance? I use many RTimer in my application to draw animations, |
|
User login
|
|
| Tue, 2008-02-26 03:20 | |
|
Do too many RTimer aggravate system performance? I use many RTimer in my application to draw animations, |
|
Forum posts: 1197
Doesn't sound like a good design, thats for sure...
Should be pretty easy for you to break out the timer in its own class, and let it keep a list of all animatable objects you have and animate them all with just one timer.
And a lot more scalable.
Forum posts: 14
Yes, I admit that it is not a good design, but it is a flexible design. every animatable object has different interval, so it is very difficult to manage them. I accept your design is more better. thanks a lot! in fact, I had already used the desing in my application.
Forum posts: 1964
I am not sure that many timers have a significant impact, that is the time that you spend in the RunL which has a significant one. I am not a game designer but I find your architecture quite weird. Does any of your animated object have to regenerate a full offscreen bitmap to update its position ? If yes, then the problem is there!
Eric Bustarret
NewLC Founder & CEO / Professional Symbian OS Consultant
Forum posts: 1197
Dividing your work into lots of timers will also mean more context switches, and more overhead in the active scheduler, and I'm sure there is some limit on number of timers you can have in your thread...
Also, your framerate will be quite... weird... when do you decide to draw the object? I hope that too isn't happening on every timer tick..
And you will also have problems with tearing without any easy way to fix it.
And possibly flicker too if you are moving stuff around..
A better way to view your animation system is too look at the framerate you want to achieve, and divide animation and rendering in two.
Set your timer to animate at the framerate you want, and update the state of your animation objects depending on the current time.
That way you will get much more even animations, and you will not make any unnecessary work.
When updating the state, calculate at what time the next state update will happen (aCurrTime + iInterval), and then the next time this object gets its "Animate(iCurrTime)" call, check if this time has expired. if not, do nothing, if it has, update and repeat.
Then draw everything on one call, after having updated all states.
Simple and very flexible and scalable design.
When you get sick of the tearing you will have, then you can easily fix it by letting your single "Render" call use offscreen buffers and using the Direct Screen Bitmap...