> We try to fire the timer rapidly, but if we get bogged down, it just won't > fire until later; when it actually does fire, we update our state > based on how much time has really passed instead of how many times the timer > has triggered.
In this case, something is not working as expected (at least on Linux), because when I test on the download shelf slide animation, the number of AnimationProgressed calls is exactly what one would calculate based on the frame rate and duration, even if I put a Sleep(1000) in the middle of the callback. Reading the Animation code, it seems the number of iterations is hard coded at the start: iteration_count_ = duration_ / timer_interval_; So we don't update our state on how much time has actually passed, we update it based on the number of times the timer has fired. It would be easy enough to fix this to do as you say while only touching the Animation class, although on a very bogged down machine the effect would be that instead of having some slow-looking animation we have a jerky (but fast!) animation. I personally think that trade-off is worth it, maybe others don't? > I'm not sure how to deal with this other than to create a separate queue of > "events triggered by animations" and let later updates overwrite earlier > ones that haven't yet been processed; that would be really hard to plumb, > though. Hmm, why would we need a separate queue for that? Seems we could search for other animation events when dequeueing an animation event on the normal message loop. But the above fix seems cleaner/safer anyway. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
