Intent to Ship: rAF aligned touch events

[Dave Tapuska]

Contact emails: dtap...@chromium.org

Spec: The design doc is posted here. 

https://docs.google.com/document/d/1aM9AqyYuceRHOmsJZXFKcgi_D4jvFAymYvI36OEwIpI/edit

Summary:

Move the timing of the handling of touchmove events so that it occurs in between when the compositor starts the BeginMainFrame callback and before blink receives it. This allows input to be injected prior to the the document life-cycle updates.

The only web platform visible output of this change is that the events will be received closer to rAF callback time and that the events should occur relatively to the frequency of the display.

There are currently a number of throttling mechanisms related to touchmove and we would like to standardize on the handling of continuous input events right before the rAF callback.

Is this feature supported on all six Blink platforms (Windows, Mac, 

Linux, Chrome OS, Android, and Android WebView)? 

Yes

Interoperability and Compatibility Risk: 

The current timing of the events is undefined and can fire at any given time. 

The frequency of events should not be a concern on Android since the native OS already does vsync alignment. Finch trials slow no negative impacts to time to update the display after first scroll. If any, the benefits show an statistical improvement of about 2.9% at 75th percentile; but the confidence decreases at the higher percentiles.

However, other platforms such as Windows do not align the touch events to the vsync signal. For Windows; Canary and Dev channels show no statistical meaningful difference. The main change is that the frequency of touch events will be significantly decreased on Windows and the escape hatch for that is the now approved getCoalesced points API. Impacted applications would need to move to pointer events model from the touch event model; but I believe this to be a good trade-off due to the benefits of the pointer event processing model.

I'd like to proceed with an intent to ship and monitor the UMA data appropriately.

Link to entry on Chrome Platform Status: 

https://www.chromestatus.com/feature/4892570664566784

Requesting approval to ship: 

Yes in M58

[Dimitri Glazkov]

LGTM1.

[Chris Harrelson]

LGTM2

LGTM1.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

LGTM3, but I wonder if there's a spec that covers this? While it's not easy to write code that breaks due to the difference in timing, pages might still have a requestAnimationFrame that becomes redundant and that could be dropped if all browsers align these events with animation frames, and that's more likely if a spec says so.

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