Intent to Ship: lowLatency canvas contexts (now: |desynchronized|)

[Miguel Casas-Sanchez]

Contact emails

mca...@chromium.org, fs...@chromium.org, tbuc...@chromium.org (use cases)

Spec

https://html.spec.whatwg.org/multipage/canvas.html#concept-canvas-desynchronized

https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.2.1 (see |desynchronized| entries)

Most of the discussion happened in https://github.com/whatwg/html/pull/4234 (then moved to  https://github.com/whatwg/html/pull/4360), the WebGL counterpart discussion happened in https://github.com/KhronosGroup/WebGL/pull/2753.

FTR the Issue was: https://github.com/whatwg/html/issues/4087

Note that the name of the flag changed from |lowLatency| to |desynchronized| along the reviewing process.

Some info in : tinyurl.com/lowlatency-canvas-on-chromeos

Summary

This ITS covers taking the |desynchronized| canvas context creation attribute, which does two things to the canvas contexts, quoting the Spec the UA will do: "desynchronizing the canvas paint cycle from the event loop, bypassing the ordinary user agent rendering algorithm, or both."

Link to “Intent to Implement” blink-dev discussion

Link to the blink-dev discussion about implementation. Here’s a link to the Google Groups page for blink-dev.

Link to Origin Trial feedback summary

There was an OT which finished after an extension in M74.

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

All platforms support the desynchronization between input events and compositor frame, CrOs supports also front-buffer rendering (these two map 1:1 to the "Summary" Section above). Plans exist to support Windows

Demo link

https://codepen.io/miguelao/full/ZjJNNw 2D 

https://codepen.io/miguelao/full/WKZaqd WebGL

Risks

Interoperability and Compatibility

The |desynchronized| attribute is a hint to the UA to configure itself in a certain mode, but the UA is not forced to honour it in any way. Apps can read back the value of this flag to query if the UA actually supports |desynchronized| or not.

Edge: Public support @travisleithead https://github.com/whatwg/html/pull/4360#pullrequestreview-212540349

Firefox: Public support @jdashg approved the PR right after https://github.com/whatwg/html/pull/4360#issuecomment-473067854 (https://bugzilla.mozilla.org/show_bug.cgi?id=1536809

Safari: Public support @othermaciej https://github.com/whatwg/html/pull/4360#pullrequestreview-215367796(https://bugs.webkit.org/show_bug.cgi?id=196002)

Web / Framework developers: Positive (wf...@google.com as part of the Blick team)

Activation

It'd be great, and we'll be working on producing a developers.google.com entry (or a MDN one) on best practices to use this flag and operating mode.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://github.com/web-platform-tests/wpt/commit/9b61fe992be8f4e0fcda8ef78ec70aabfcf0a3e1

is a minimal WPT entry covering the platform recognizing the |desynchronized| dictionary entry; nothing else can be tested at this level since it's just a hint and implementation specific.

Entry on the feature dashboard

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

[Philip Jägenstedt]

LGTM1, looks like a solid platform change that's had input from many parties already.

I guess that this will be behind a runtime flag and disabled on Windows until it can be supported there, so that feature detection works?

Although the tests are shallow, I don't see how this could be tested much deeper in a cross-browser way, since the effect is timing of rasterization and possible tearing, neither of which could be tested in a non-flaky way even by capturing video of the browser output. So, unit tests of all the layers involved seems like a superior testing strategy here.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUS084SP9cyTwZau%2Bh1%2Bmxee6iR-2UFkTm1qHsrXJ0xsuYaPg%40mail.gmail.com.

[Daniel Bratell]

LGTM2

@foolip, testing of hints is always difficult because there would be nothing wrong with ignoring it. For a Chromium regression test, you'd really want to confirm that latency is indeed lower, and then you run into performance testing territory. I'd be happy to see more tests of various kinds, but I imagine it will not be trivial.

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeW%3DJdZuxAUJYUweyrLKOyJ%2BW4e5dzPieQFY9TfEOR5BQ%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Miguel Casas-Sanchez]

On Thu, 28 Mar 2019 at 11:36, Philip Jägenstedt <foo...@chromium.org> wrote:

LGTM1, looks like a solid platform change that's had input from many parties already.

I guess that this will be behind a runtime flag and disabled on Windows until it can be supported there, so that feature detection works?

Feature detection-wise, a client can just read back the |desynchronized| (nee |lowLatency|) to verify if the UA actually supports lowLatency;   

  let c= canvas.getContext('2d', { desynchronized: true});

  if (c.getContextAttributes().desynchronized === undefined || c.getContextAttributes().desynchronized == false)

    console.log('Low latency canvas not supported, boo!");

  else 

    console.log('Low latency canvas supported, yay!");

An app would be wise to react to this and fall back to some "normal" non-lowLatency path if this is not supported at all.

[Chris Harrelson]

LGTM3

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUS087etnxiz8Ua69CbUu931Mqz3K_oijhp--PbB5Xn_fEeaA%40mail.gmail.com.