Intent to Prototype: Delegated Ink Trail
mab...@microsoft.com
Explainer
Design doc/Spec
TAG review
Summary
Due to the pipelined nature of rendering web pages followed by the similarly pipelined nature of OS composition, there can be a significant amount of latency from the time the user interacts with something to when the screen displays the result. The goal of this feature is to enable web applications to describe the last rendered input point with sufficient detail so that the browser or operating system can present segments of the ink trail for input that has been delivered, but not yet rendered (the pointer trail). This will result in a large portion of the rendering pipeline being skipped, allowing for lower latency between page interaction and displayed results.
Motivation
Achieving low latency is critical for delivering great inking experiences on the Web. Ink on the Web is generally produced by consuming PointerEvents and rendering strokes to the application view. The goal of this feature is to be a compact and easy to use progressive enhancement over what is already available to developers to reduce latency in inking scenarios.
One common strategy for reducing latency currently is to use desynchronized canvas with pointerrawmove events. However, a drawback of this strategy is that when desynchronized canvas is used to improve inking performance, there is no guarantee that the "dried ink" (previously rendered) content shows up in the same frame as the "wet ink" stroke just received. This can end up producing one frame with no ink content, or one frame where both wet and dry ink are visible, which results in a visual artifact of a flash of darker for non-opaque strokes.
(See explainer for more comprehensive motivation.)
Risks
Interoperability and Compatibility
Dependent on OS capabilities for biggest improvements. Because it is a progressive enhancement over what is currently available, the core experience offered by a site using this wouldn’t be impacted. Since it is strictly opt-in, there are no compatibility concerns.
Firefox: No public signals
Edge: Public support (https://github.com/w3c/pointerevents/issues/204) Initial discussion w/Edge & Google folks.
Safari: No public signals
Web developers: No signals
Ergonomics
Because inking on the web is most commonly accomplished by rendering strokes to a canvas element, canvas is likely to be frequently used with this feature.
This feature will have no impact on the browser's ability to maintain good performance.
Activation
The feature will be behind a flag, but will not be difficult for developers to take advantage of once enabled. It is design to be a compact API, and would only require a single extra JavaScript call added to the existing ink renderer in most cases.
There is no extra work needed by DevTools to support this feature. Trace Events will be added to aid in debugging via about://tracing.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes, the initial version will be as it will be implemented within the browser. However, the end goal is for it to use an upcoming Windows 10 API to further reduce latency, which will only be supported on Windows 10. The hope is that other operating systems will eventually add support for similar APIs and the feature can then be extended to use these APIs on other platforms to gain further latency reduction beyond the browser implementation.
Link to entry on the Chrome Platform Status
Requesting approval to ship?
No