The scroll animation doesn't actually run until the compositing update (ScrollAnimator::updateCompositorAnimations).It looks like we wait until there are no pending input events before starting the main frame. So if they come in faster than we can handle them (due to slow listeners) the main frame can be arbitrarily delayed.On Wed, Nov 30, 2016 at 7:45 AM, Tim Dresser <tdre...@google.com> wrote:I'm not sure if this behavior is correct, but I find it a bit surprising.https://output.jsbin.com/rofajo adds a keydown listener which waits 1 second.If I hit the down key twice, I wait 2 seconds, and then the page scrolls down.Shouldn't I wait 1 second, and see half the scroll, and then wait another second, and see the remaining scroll?
--
You received this message because you are subscribed to the Google Groups "input-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.
Compositing and input tasks currently always run in order, which I think explains the behavior you're seeing.
To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "input-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAPuLczvV0BspQBYtd%2B8j%2BT6SGXJU6WAXNj-6hi_aZpX_xh1B8Q%40mail.gmail.com.