Intent to Implement and Experiment: rAF Aligned Input

[Dave Tapuska]

Contact Emails

dtap...@chromium.org

Summary

Continuous events (mousemove, mousewheel, touchmove) are currently dispatched when they are received. Processing these events just before rAF occurs increases performance because less events don't produce a frame are handled. Non-continuous events (discrete) events will continue to be processed immediately.

Design Doc

Brief motivation and design doc rAF Aligned Input

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes

Compatibility Risk
We risk breaking apps that require >60 Hz mousemove events. touchmove on android is delivered at 60 Hz so it should cause no issues for touch events.

Experimentation Timeline

We are planning on experimenting in Canary and Dev only until we get some initial data of what kind of performance benefits we see. We have added UMA metrics to count how often we hold onto events for and how many we coalesce due to the experiment.

OWP launch tracking bug
crbug.com/642368

Link to entry on the feature dashboard
https://www.chromestatus.com/features/4892570664566784

[Chris Harrelson]

Hi,

Since it's only canary and dev, I assume you don't intend to use an origin trial, but just turn on the feature? Is that correct?

Chris

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

[Dave Tapuska]

It is not an origin trial. We are just going to do a 50/50 trial.

Sorry if I used the "Experiment" intent incorrectly for this. I just wanted to communicate what we are doing.

dave.

[Michael Thiessen]

To clarify, do you mean that you risk breaking apps that require mouseevents at a greater frequency than the display update frequency? 120/144Hz displays are becoming more common for desktop, and mouse events (and rAF) there would be expected to fire at 120/144Hz.

[Lucas Garron]

Do you have an estimate of how much this would delay input events?

For example, I have written several web apps with timers (e.g. https://timer.cubing.net/) whose main goal is to record an accurate time, and it would be nice to know how much accuracy I might losing (even if the current situation is also not clear). Is it up to 1/60 of a second on most devices? Could rAF alignment result in receiving delayed inputs that sometimes push it to 1/30?

»Lucas   

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

--
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+...@chromium.org.

[Dave Tapuska]

In your app I only see one touchmove handler and that preventDefaults the scroll. Really you could get better performance without having the touchmove handler by using touch-action instead. And for your example all other events you bind to are discrete (non-continuous) events so there is no change with respect to those. Once you get a discrete event in the queue it flushes all continuous events to be processed right away so there is no real delay for the discrete event.

For touchmove, mousemove and mousewheel the delay would be at most a slightly less than a frame. Assuming an event arrived just after the frame signal was processed; it would need to wait around for the next frame signal. So for most devices it could add approximately 1/60th of a second to processing delay.

dave.

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

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

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

[Dave Tapuska]

Yes whatever speed rAF fires at and it is vsync driven on some platforms. So it could fire at 120Hz or 144Hz depending on the hardware.

dave.

[Rick Byers]

Yes, this is just an "intent to implement" so no LGTMs required.  Finch trials on dev/canary only don't require any approvals.

For example, I have written several web apps with timers (e.g. https://timer.cubing.net/) whose main goal is to record an accurate time, and it would be nice to know how much accuracy I might losing (even if the current situation is also not clear). Is it up to 1/60 of a second on most devices? Could rAF alignment result in receiving delayed inputs that sometimes push it to 1/30?

This is a great use case for our high-resultion input timestamps.  If you use the timeStamp on the event to decide when to really start/end your clock then you should get a more accurate time (not impacted by any delays caused by rendering / javascript).

On Mon, Sep 12, 2016 at 4:04 PM, Dave Tapuska <dtap...@chromium.org> wrote: