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.

>
> > 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to