On Fri, Oct 2, 2009 at 2:02 PM, John Abd-El-Malek <[email protected]> wrote:
> > > On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade <[email protected]> wrote: > >> >> > 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 also agree this is the better tradeoff. Better to have a jerky animation > than slowing the machine even more. > >From the 3D Graphics background: when skipping frames, time-driven animations feel infinitely less jerky than frame-driven ones. I think it's mostly the same with video. I.E. use time, not ticks. Antoine --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
