Scheduling differences between first and other touch moves

[Tim Dresser]

I'm seeing some odd histograms for Event.Latency.TouchToFirstScrollUpdateSwapBegin on LINK.

It almost looks like we aren't applying the deadline here. I would have expected to see something that looks more like Event.Latency.TouchToScrollUpdateSwapBegin.

This looks like we're trying to postpone the swap until we hit 16ms.

We expect to see that the first touchmove event is more expensive than other touchmove events, but we see the opposite trend here.

Is there any reason that we'd schedule the first touchmove differently from other touchmoves?

Thanks!
Tim

[Sami Kyostila]

Is there some input buffering and/or vsync aligning happening here? If the first touch event comes in at a random offset in the frame but subsequent ones are snapped to vsync, the graphs might look a little something like that.

- Sami

--
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/CAHTsfZA4sHq0_OVJPkcFDgvOP18WZ12kH58L2YhBOvtseY3iUA%40mail.gmail.com.

[Tim Ansell]

On 1 December 2015 at 04:54, 'Sami Kyostila' via input-dev <inpu...@chromium.org> wrote:

Is there some input buffering and/or vsync aligning happening here? If the first touch event comes in at a random offset in the frame but subsequent ones are snapped to vsync, the graphs might look a little something like that.

- Sami

2015-11-30 15:31 GMT+00:00 'Tim Dresser' via scheduler-dev <schedu...@chromium.org>:

I'm seeing some odd histograms for Event.Latency.TouchToFirstScrollUpdateSwapBegin on LINK.

It almost looks like we aren't applying the deadline here. I would have expected to see something that looks more like Event.Latency.TouchToScrollUpdateSwapBegin.

This looks like we're trying to postpone the swap until we hit 16ms.

This might be a red-herring but there are actually a number of cases which cause us to postponing the DrawAndSwap till we hit 16ms. Being swap throttled is one cause.

https://code.google.com/p/chromium/codesearch#chromium/src/cc/scheduler/scheduler.cc&rcl=1448901293&l=576

and

https://code.google.com/p/chromium/codesearch#chromium/src/cc/scheduler/scheduler_state_machine.cc&sq=package:chromium&type=cs&l=923&rcl=1448901293

Sunny knows the deadline changing code much better then I do.

Tim 'mithro' Ansell

[Tim Dresser]

The effect appears to be strongest on LINK, PEPPY doesn't show it very strongly at all.

I thought we might be seeing lower latency for the first touchmove due to the main thread getting busier during scroll, but that doesn't align well with the fact that PEPPY sees 9 times more main thread scrolling than LINK, but PEPPY doesn't have this issues nearly as strongly.

[Tim Ansell]

How does LINK / PEPPY names map to hardware names I might understand?

Is the LINK a low end device or a device with a very large screen which is more likely to be swap throttled?

Tim 'mithro' Ansell

PS Brian, how are those Swap Throttled metrics going?

[Tim Dresser]

Sorry:
Link -> Chromebook Pixel 1
Peppy -> Acer 720P

[Tim Dresser]

Here's a trace from LINK, containing 5 touch scroll gestures.

The trace was taken on https://en.wikipedia.org/wiki/Test_(Unix).

3 out of the 5 scrolling gestures have a first GSU latencyInfo which is significantly shorter than the other latencyInfo's in the gesture. It looks like we frequently respond to the first touch move in one frame, but then for later touch moves we have an extra frame of latency.

Are there any tracing categories I should add here?

Any thoughts on what's going on?

[Sami Kyostila]

Is this a case of being swap throttled in the GPU driver? After the GPU thread blocks for 16ms before every swap waiting for the page flip and every input event is delayed by at least that time.

Looks like on the very first frame the browser compositor does two frame swaps instead of one. Anyone know why?

- Sami

[Tim Dresser]

Bug filed here.

The behavior still occurs on static pages (traces in the bug).

It looks like leaving more idle time before starting the next scroll increases the likelihood that we'll have a short first gesture scroll update.