[chromium-dev] Re: Jank: performance and animation frame rates
On Fri, Oct 2, 2009 at 11:57 AM, Evan Stade est...@chromium.org wrote: It would be nice to have some mechanism for telling the animation we are done with the last update, ready for another. AFAIK this is already what effectively happens. 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. Maybe, though, what you're seeing is that we don't bog down on the UI thread where the timer is firing, so we end up doing a lot of updates, but these updates can (for some animations) create a backlog of events on other threads/processes, which may take a while to be dealt with? 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. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Jank: performance and animation frame rates
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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Jank: performance and animation frame rates
On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org wrote: 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. That sounds very wrong. Please treat that as a bug. 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. I mean for eventstriggered by animation events. Let's say the download shelf animation resizes the download shelf, which resizes the content area, which sends a message to the renderer to relayout at the new size. Now the renderer process his a resize cued up that in theory should be canceled by a future resize from the animation but in practice wouldn't be. Of course this example is bogus because IIRC the renderer already collapses resize requests, to deal with mases like moving the mouse around a lot while resizing. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Jank: performance and animation frame rates
On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Jank: performance and animation frame rates
On Fri, Oct 2, 2009 at 2:02 PM, John Abd-El-Malek j...@chromium.org wrote: On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Jank: performance and animation frame rates
On Fri, Oct 2, 2009 at 2:07 PM, Antoine Labour pi...@google.com wrote: On Fri, Oct 2, 2009 at 2:02 PM, John Abd-El-Malek j...@chromium.org wrote: On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org 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 FYI: http://codereview.chromium.org/257038/show --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
