Re: Odd smooth scroll behavior

[Timothy Dresser]

+scheduler-dev +input-dev 

Bummer.

For wheel and touchpad scroll, coalescing fixes this problem for us, if I understand correctly.

For keyboard though, we can't coalesce. I wonder if the scheduler should do something different here?

Tim

On Wed, Nov 30, 2016 at 3:01 PM Steve Kobes <sko...@google.com> wrote:

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?

[Sami Kyostila]

Compositing and input tasks currently always run in order, which I think explains the behavior you're seeing. I'm not sure what could break if we reordered them, but at least in this case it would decrease scroll latency but increase input latency for the second keyboard event. It's hard to say if this is always the right tradeoff.

- Sami

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

[Timothy Dresser]

Yeah, I'm not certain what the right approach is here.

The right next step is probably to gather some data on keyboard driven scroll performance, to determine if there's actually a problem here.

I'll swing back once we've got this data.

[Steve Kobes]

On Thu, Dec 1, 2016 at 3:34 AM, Sami Kyostila <skyo...@chromium.org> wrote:

Compositing and input tasks currently always run in order, which I think explains the behavior you're seeing.

I'm a little unclear on what "in order" means here... aren't the main frame tasks driven by vsync?  Since the first input task takes longer than 16ms it seems like we ought to have a frame before the second input task.  Wouldn't it already be queued before the second input occurs?

[Sami Kyostila]

With vsync-driven input (i.e., ~one input event per frame) that would be true, but I'm guessing keyboard input doesn't work like that at the moment and we end up having multiple input events already queued before the BeginFrame triggered by the first one is scheduled.

- Sami

[Steve Kobes]

The flow is like this:

1. user presses ↓ key

2. RenderView gets input event, starts JS listener with 1000ms busy loop

... ~500ms later ...

3. user presses ↓ key again

... ~500ms later ...

4. first input task completes

5. second input task (from #3) begins

... 1000 ms later ...

6. second input task completes

7. cc::ProxyMain::BeginMainFrame runs, starting the scroll animation

So my possibly dumb question is, why don't we *queue* a BeginMainFrame between #2 and #3?  That way it would run between #4 and #5.

To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+unsubscribe@chromium.org.

[Sami Kyostila]

Not a dumb question at all. The reason why there's no BeginMainFrame between #2 and #3 is that we only know that we want to scroll after the first 1000ms delay and that's when we request the BeginMainFrame. This means that as long as the second input happens inside that 1000ms window, it will always get queued before the BeginMainFrame.

One way to fix this would be to speculatively request a BeginMainFrame before we start processing input. It'll be wrong some of the time, but I'd assume most input events would benefit from it.

Here's a tentative patch that seems to work well on that jsbin page: https://codereview.chromium.org/2545423002. Tim, WDYT?

- Sami

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.

[Timothy Dresser]

Thanks Steve and Sami for clarifying this!

What's the cost of triggering a BeginMainFrame when we shouldn't have? At worst, it should increase power consumption (or perhaps thread contention), right?

I think there are a few paths forward here:

1. Add an UMA to see how often input triggers a BeginMainFrame, to see how often this would trigger BeginMainFrames needlessly.
   
2. Launch via Finch, with an UMA measuring how often this triggers BeginMainFrames needlessly.
3. Launch without gathering any data.
   

I'm inclined to launch this via Finch, with data collection, for keyboard input only (#2). We can rAF align all the other input modalities which trigger scrolling, but we can't rAF align keyboard input (because the number of times the button is pressed matters, and there's no field in the keyboard event we could use to indicate that multiple events have been aggregated together.

Does that sound reasonable?

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.

[Timothy Dresser]

What metrics would we expect to improve with this change? We may also need to add additional coverage for keyboard input latency.

[Sami Kyostila]

Limiting this to just keyboard events sounds good.

The additional cost is basically an extra wakeup for the next vsync + some IPC, i.e., not a whole lot. The compositor is already pretty good at earlying-out of no-op frames. This would only happen when a (keyboard) input event does not trigger animation -- I don't have data but I have a hunch that it's pretty rare.

I'd expect this to decrease end-to-end keyboard event latency (do we have that?)

How often would we be okay with this being wrong? Given the cost of a miss is pretty low I don't we need it to be totally accurate.

- Sami

[Timothy Dresser]

We don't have a good measure of end-to-end keyboard event latency.

I've filed a bug for this here, blocked on adding better latency metrics.

I'll follow up once we've got those metrics in place.

[Timothy Dresser]

End to end key latency metric is here.

We should probably do this behind a finch trial.

Does it make more sense for input or scheduling to drive this work?

Tim

[Sami Kyostila]

Let's chat about that in today's meeting.

- Sami