Intent to Ship: Compute Pressure

[Mandy, Arnaud]

Contact emails

kenneth.r.c...@intel.com, arnaud...@intel.com, wei4...@intel.com, raphael.ku...@intel.com

Explainer

https://github.com/w3c/compute-pressure/blob/main/README.md

Specification

https://www.w3.org/TR/compute-pressure

Summary

The Compute Pressure API offers high-level states that represent the pressure on the system. It allows the implementation to use underlying hardware/platform metrics to inform the API users of possible stress (high CPU load at the moment) on the system and consequently take the corrective actions needed.

“Pressure” is a generic term by design – at the moment it is calculated based on CPU load, but future plans include using signals from temperature and battery status, for example.

https://developer.chrome.com/docs/web-platform/compute-pressure/

Blink component

Blink>PerformanceAPIs>ComputePressure

Search tags

compute pressure

TAG review

spec review: https://github.com/w3ctag/design-reviews/issues/795

wide review tracker: https://github.com/w3c/compute-pressure/issues/177

TAG review status

Issues addressed

Chromium Trial Name

ComputePressure

Origin Trial documentation link

https://developer.chrome.com/docs/web-platform/compute-pressure/

Origin Trials history

The first Origin Trial was run between M92-94.

The Compute Pressure API was widely redesigned after this OT to resemble existing observer-based web APIs and also to provide better privacy and security guarantees after discussions with PING.

The second Origin Trial took place during M115-M120.
During this origin trial we realized that the full capacity of the API couldn’t be tested due to a lack of support for third-party tokens. An Origin Trial extension was necessary until M123.

Risks

Interoperability and Compatibility

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/521)

WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html) This issue has been taken into account: https://github.com/w3c/compute-pressure/issues/24

Web developers: Positive (https://github.com/w3c/compute-pressure/issues/14)

Other signals:

Security

https://github.com/w3c/compute-pressure/issues/79

WebView application risks

No

Debuggability

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

No,
Windows, Linux, ChromeOs, Mac.

Support on Android (incl. Android WebView) has been deprioritized as there is no current way to access the telemetry needed after Android 11, and the current partners we are engaging with have no need as they are using native solutions on Android at this point.

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/compute-pressure?run_id=5116280230641664

The wpt.fyi results are flaky due to WPT bug 44438

DevTrial instructions

https://github.com/w3c/compute-pressure/blob/main/HOWTO.md

Flag name on chrome://flags

see https://github.com/w3c/compute-pressure/blob/main/HOWTO.md

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1067627

Launch bug

https://crbug.com/1173266

Sample links

https://w3c.github.io/compute-pressure/demo

Estimated milestones

OriginTrial desktop extension	123
OriginTrial desktop last	118
OriginTrial desktop first	115
OriginTrial desktop last	94
OriginTrial desktop first	92
DevTrial on desktop	109

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5597608644968448

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/LTIRZ24C5Os/m/BPSeJ8y0BwAJ

 Ready for Trial: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/-1ciwdn23J4

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/QfJ4pngu3gc

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/HzVV-sM97T0

Intent to Extend Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/s83S7wXxa6E/m/AjvsIJxmAQAJ

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

Can you add a comment to this issue pointing to this I2S, and any relevant changes since the original issue was opened?

WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html) This issue has been taken into account: https://github.com/w3c/compute-pressure/issues/24

https://github.com/w3c/compute-pressure/issues/24#issuecomment-1022516116 suggests asking for re-review once issue 24 is settled (at least that's my interpretation). Do you know if that ever happened?

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DS0PR11MB7902DDE9FBF54F29CFD8312593222%40DS0PR11MB7902.namprd11.prod.outlook.com.

[Reilly Grant]

Is there any developer feedback that can be shared from the origin trials? I'm looking for signals that developers have been able to improve user experiences by using the new signals. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68e05b3e-18c8-4330-8b67-b55cbd5bfdb1%40chromium.org.

[Yoav Weiss (@Shopify)]

+1. That would be great feedback to have! 

Risks

Interoperability and Compatibility

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/521)

Can you add a comment to this issue pointing to this I2S, and any relevant changes since the original issue was opened?

WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html) This issue has been taken into account: https://github.com/w3c/compute-pressure/issues/24

Skimming through the issues raised from WebKit folks, I believe y'all addressed the privacy issues in https://github.com/w3c/compute-pressure/issues/197.

The other issue raised is around the usefulness (or lack thereof) of apps changing behavior based on system load, rather than based on the time is takes them to achieve certain tasks. Was that discussed somewhere?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMaeM0B-mmgK5DO_a57WbRzf3BBkK724QJL5%3DqG5NFxgOA%40mail.gmail.com.

[Arnaud Mandy]

Reilly, 

We do not have direct access (non-googlers) to the OT feedback unfortunately. 
We are working with our google contact to publish a summary.

[Manuel Rego Casasnovas]

The TAG asked to be updated after the experimental phase, but the issue
hasn't been updated yet:
https://github.com/w3ctag/design-reviews/issues/795#issuecomment-1691188175

Also for WebKit position, we might want to fill a new issue in the new
place: https://github.com/webkit/standards-positions/
And explain what has changed from the email in 2021.

Cheers,
Rego

On 06/03/2024 09:14, Arnaud Mandy wrote:
> Reilly,
>
> We do not have direct access (non-googlers) to the OT feedback
> unfortunately.
> We are working with our google contact to publish a summary.
>
> On Tuesday, March 5, 2024 at 8:14:45 PM UTC+2 rei...@chromium.org wrote:
>
> On Tue, Mar 5, 2024 at 5:56 AM Mike Taylor <mike...@chromium.org> wrote:
>

> __

>
>
> On 3/5/24 6:57 AM, Mandy, Arnaud wrote:
>>
>>
>> Contact emails
>>
>> kenneth.r.c...@intel.com, arnaud...@intel.com,
>> wei4...@intel.com, raphael.ku...@intel.com
>>
>>
>> Explainer
>>
>> https://github.com/w3c/compute-pressure/blob/main/README.md
>> <https://github.com/w3c/compute-pressure/blob/main/README.md>
>>
>>
>> Specification
>>
>> https://www.w3.org/TR/compute-pressure
>> <https://www.w3.org/TR/compute-pressure>
>>
>>
>> Summary
>>
>> The Compute Pressure API offers high-level states that
>> represent the pressure on the system. It allows the
>> implementation to use underlying hardware/platform metrics to
>> inform the API users of possible stress (high CPU load at the
>> moment) on the system and consequently take the corrective
>> actions needed.
>>
>> “Pressure” is a generic term by design – at the moment it is
>> calculated based on CPU load, but future plans include using
>> signals from temperature and battery status, for example.
>>
>>

>> https://developer.chrome.com/docs/web-platform/compute-pressure/ <https://developer.chrome.com/docs/web-platform/compute-pressure/>

>>
>>
>> Blink component
>>
>> Blink>PerformanceAPIs>ComputePressure

>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs%3EComputePressure>
>>
>>
>> Search tags
>>
>> compute pressure
>> <https://chromestatus.com/features#tags:compute%20pressure>

>>
>>
>> TAG review
>>
>> spec review:
>> https://github.com/w3ctag/design-reviews/issues/795
>> <https://github.com/w3ctag/design-reviews/issues/795>
>>
>> wide review tracker:
>> https://github.com/w3c/compute-pressure/issues/177
>> <https://github.com/w3c/compute-pressure/issues/177>
>>
>>
>> TAG review status
>>
>> Issues addressed
>>
>>
>> Chromium Trial Name
>>
>> ComputePressure
>>
>>
>> Origin Trial documentation link
>>

>> https://developer.chrome.com/docs/web-platform/compute-pressure/ <https://developer.chrome.com/docs/web-platform/compute-pressure/>

>>
>>
>> Origin Trials history
>>
>> The first Origin Trial

>> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/HzVV-sM97T0/m/3pQ311KHAAAJ> was run between M92-94.

>>
>> The Compute Pressure API was widely redesigned after this OT
>> to resemble existing observer-based web APIs and also to
>> provide better privacy and security guarantees after
>> discussions with PING.
>>
>>
>> The second Origin Trial

>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/QfJ4pngu3gc> took place during M115-M120.

>> During this origin trial we realized that the full capacity of
>> the API couldn’t be tested due to a lack of support for
>> third-party tokens. An Origin Trial extension

>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/s83S7wXxa6E/m/AjvsIJxmAQAJ> was necessary until M123.

>>
> Is there any developer feedback that can be shared from the origin
> trials? I'm looking for signals that developers have been able to
> improve user experiences by using the new signals.
>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>

>> /Gecko/: No signal
>> (https://github.com/mozilla/standards-positions/issues/521
>> <https://github.com/mozilla/standards-positions/issues/521>)

>>
> Can you add a comment to this issue pointing to this I2S, and
> any relevant changes since the original issue was opened?
>>

>> /WebKit/: Negative
>> (https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html <https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html>) This issue has been taken into account: https://github.com/w3c/compute-pressure/issues/24 <https://github.com/w3c/compute-pressure/issues/24>
>>
> https://github.com/w3c/compute-pressure/issues/24#issuecomment-1022516116 <https://github.com/w3c/compute-pressure/issues/24#issuecomment-1022516116> suggests asking for re-review once issue 24 is settled (at least that's my interpretation). Do you know if that ever happened?
>>
>> /Web developers/: Positive
>> (https://github.com/w3c/compute-pressure/issues/14
>> <https://github.com/w3c/compute-pressure/issues/14>)
>>
>>
>> /Other signals/:
>>
>>
>> Security
>>
>> https://github.com/w3c/compute-pressure/issues/79

>> <https://github.com/w3c/compute-pressure/issues/79>
>>
>>
>> WebView application risks
>>
>> No
>>
>>
>> Debuggability
>>
>>
>> Will this feature be supported on all six Blink
>> platforms (Windows, Mac, Linux, ChromeOS, Android, and
>> Android WebView)?
>>
>> No,
>> Windows, Linux, ChromeOs, Mac.
>>
>> Support on Android (incl. Android WebView) has been
>> deprioritized as there is no current way to access the
>> telemetry needed after Android 11, and the current partners we
>> are engaging with have no need as they are using native
>> solutions on Android at this point.
>>
>>
>> Is this feature fully tested by web-platform-tests

>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
>>
>> Yes
>> https://wpt.fyi/results/compute-pressure?run_id=5116280230641664 <https://wpt.fyi/results/compute-pressure?run_id=5116280230641664>

>>
>> The wpt.fyi results are flaky due to WPT bug 44438

>> <https://github.com/web-platform-tests/wpt/issues/44438>
>>
>>
>> DevTrial instructions
>>
>> https://github.com/w3c/compute-pressure/blob/main/HOWTO.md

>> <https://github.com/w3c/compute-pressure/blob/main/HOWTO.md>
>>
>>
>> Flag name on chrome://flags
>>
>> see https://github.com/w3c/compute-pressure/blob/main/HOWTO.md
>> <https://github.com/w3c/compute-pressure/blob/main/HOWTO.md>
>>
>>
>> Finch feature name
>>
>> None
>>
>>
>> Non-finch justification
>>
>> None
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>>
>> Tracking bug
>>

>> https://crbug.com/1067627 <https://crbug.com/1067627>
>>
>>
>> Launch bug
>>
>> https://crbug.com/1173266 <https://crbug.com/1173266>

>>
>>
>> Sample links
>>
>> https://w3c.github.io/compute-pressure/demo
>> <https://w3c.github.io/compute-pressure/demo>
>>
>>
>> Estimated milestones
>>
>> OriginTrial desktop extension
>>
>>
>>
>> 123
>>
>> OriginTrial desktop last
>>
>>
>>
>> 118
>>
>> OriginTrial desktop first
>>
>>
>>
>> 115
>>
>> OriginTrial desktop last
>>
>>
>>
>> 94
>>
>> OriginTrial desktop first
>>
>>
>>
>> 92
>>
>> DevTrial on desktop
>>
>>
>>
>> 109
>>
>>
>> Anticipated spec changes
>>
>> None
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5597608644968448
>> <https://chromestatus.com/feature/5597608644968448>
>>
>>
>> Links to previous Intent discussions
>>
>> Intent to prototype:

>> https://groups.google.com/a/chromium.org/g/blink-dev/c/LTIRZ24C5Os/m/BPSeJ8y0BwAJ <https://groups.google.com/a/chromium.org/g/blink-dev/c/LTIRZ24C5Os/m/BPSeJ8y0BwAJ>
>>
>>  Ready for Trial:
>> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/-1ciwdn23J4 <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/-1ciwdn23J4>
>>
>> Intent to Experiment:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/QfJ4pngu3gc <https://groups.google.com/a/chromium.org/g/blink-dev/c/QfJ4pngu3gc>
>>
>> Intent to Experiment:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/HzVV-sM97T0 <https://groups.google.com/a/chromium.org/g/blink-dev/c/HzVV-sM97T0>
>>
>> Intent to Extend Experiment:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/s83S7wXxa6E/m/AjvsIJxmAQAJ <https://groups.google.com/a/chromium.org/g/blink-dev/c/s83S7wXxa6E/m/AjvsIJxmAQAJ>

>>
>>
>>
>> This intent message was generated by Chrome Platform Status

>> <https://chromestatus.com/>.

>>
>> --
>> 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.
>> To view this discussion on the web visit

>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DS0PR11MB7902DDE9FBF54F29CFD8312593222%40DS0PR11MB7902.namprd11.prod.outlook.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DS0PR11MB7902DDE9FBF54F29CFD8312593222%40DS0PR11MB7902.namprd11.prod.outlook.com?utm_medium=email&utm_source=footer>.

>
> --
> 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.
>
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68e05b3e-18c8-4330-8b67-b55cbd5bfdb1%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68e05b3e-18c8-4330-8b67-b55cbd5bfdb1%40chromium.org?utm_medium=email&utm_source=footer>.

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

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e198bbc-0216-4472-9b28-69b2ca27f3bbn%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e198bbc-0216-4472-9b28-69b2ca27f3bbn%40chromium.org?utm_medium=email&utm_source=footer>.

[Kenneth Rohde Christiansen]

 

The other issue raised is around the usefulness (or lack thereof) of apps changing behavior based on system load, rather than based on the time is takes them to achieve certain tasks. Was that discussed somewhere?

That is mentioned in the README (linked to from the spec): Goals / Motivating Use Cases

Cheers,

Kenneth

 

[Yoav Weiss (@Shopify)]

On Wed, Mar 6, 2024 at 12:40 PM Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:

 

The other issue raised is around the usefulness (or lack thereof) of apps changing behavior based on system load, rather than based on the time is takes them to achieve certain tasks. Was that discussed somewhere?

That is mentioned in the README (linked to from the spec): Goals / Motivating Use Cases

I see this sentence which mentions the alternative, but doesn't really clarify why it isn't sufficient. If external pressure harms the app's ability to do what it wants to do, wouldn't that be measurable?

Cheers,

Kenneth

 

[Kenneth Rohde Christiansen]

On Wed, Mar 6, 2024 at 12:50 PM Yoav Weiss (@Shopify)
<yoav...@chromium.org> wrote:

> I see this sentence which mentions the alternative, but doesn't really clarify why it isn't sufficient. If external pressure harms the app's ability to do what it wants to do, wouldn't that be measurable?

The ability to act proactively is the differentiator. If you measure
the side-effects you're already too late. Also, a lot of our users
have been sending the data to the backend to use it to detect if there
is a correlation between when users report bad user experience and
when the pressure is high, not being able to directly tie that to one
specific task beforehand. Some tasks are also not easily measurable
like a WebRTC feed, potentially with software/hardware blurring done
by the OS.

Kenneth

[Kenneth Rohde Christiansen]

We will update the TAG issue. Thanks for pointing that out.

There is already an entry for WebKit:
https://github.com/WebKit/standards-positions/issues/255 and Jeffrey
made them aware of the mitigations we put in place.

Kenneth

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d6c29007-f0bf-4cc5-97a4-7d31ebaf3153%40igalia.com.



--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone +45 4294 9458 ﹆﹆﹆

[Kenneth Rohde Christiansen]

On Tue, Mar 5, 2024 at 7:14 PM Reilly Grant <rei...@chromium.org> wrote:

On Tue, Mar 5, 2024 at 5:56 AM Mike Taylor <mike...@chromium.org> wrote:

During this origin trial we realized that the full capacity of the API couldn’t be tested due to a lack of support for third-party tokens. An Origin Trial extension was necessary until M123.

Is there any developer feedback that can be shared from the origin trials? I'm looking for signals that developers have been able to improve user experiences by using the new signals.

Though we cannot share the exact feedback from the origin trial due to confidentiality (we also only got a summary ourselves as non-Googlers), the feedback was quite positive with all respondents extremely likely to continue using the API. None of the respondents found the API hard to use, but we received some minor feedback on the API shape and feature requests that we have adopted or at least filed issues for.

Ajay (cc'ed), might be able to share more.

Kenneth

[Ajay Rahatekar]

As Kenneth mentioned, the aggregated/anonymized feedback (largely positive) was shared with the Intel team in consultation with the Google Privacy team. Internal copy is available as needed. 

[Yoav Weiss (@Shopify)]

On Wed, Mar 6, 2024 at 4:00 PM 'Ajay Rahatekar' via blink-dev <blin...@chromium.org> wrote:

As Kenneth mentioned, the aggregated/anonymized feedback (largely positive) was shared with the Intel team in consultation with the Google Privacy team. Internal copy is available as needed. 

While a Google-internal copy is great, a public summary of that feedback would be useful for non-Google API owners and the broader community alike, and help us get a better understanding of the benefits of shipping this.

 

On Wednesday, March 6, 2024 at 5:57:47 AM UTC-8 kenneth.ch...@gmail.com wrote:

On Tue, Mar 5, 2024 at 7:14 PM Reilly Grant <rei...@chromium.org> wrote:

On Tue, Mar 5, 2024 at 5:56 AM Mike Taylor <mike...@chromium.org> wrote:

During this origin trial we realized that the full capacity of the API couldn’t be tested due to a lack of support for third-party tokens. An Origin Trial extension was necessary until M123.

Is there any developer feedback that can be shared from the origin trials? I'm looking for signals that developers have been able to improve user experiences by using the new signals.

Though we cannot share the exact feedback from the origin trial due to confidentiality (we also only got a summary ourselves as non-Googlers), the feedback was quite positive with all respondents extremely likely to continue using the API. None of the respondents found the API hard to use, but we received some minor feedback on the API shape and feature requests that we have adopted or at least filed issues for.

Ajay (cc'ed), might be able to share more.

Kenneth

--

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/143ee50c-9ff4-4dfb-860c-700155bcd065n%40chromium.org.

[Ajay Rahatekar]

Please see below for aggregated and manually vetted OT feedback that was shared as per Google's policy:

• 100% of the respondents are extremely likely to continue using the API.
• 43% of the respondents found the API 'Extremely easy', 43% found it 'Neither easy nor difficult' and 14% found it 'Moderately easy' to use.
• 7% of the respondents mentioned that they would prefer to give the callback frequency in time units (secs, milliseconds), similar to other APIs such as setInterval in place of Hz as currently designed. A number scale along with labels would be more useful e.g. { pressure: 2, label: 'nominal' }.
• 2% of the respondents suggested adjusting thresholds or combining states to reduce "flapping" between fair and nominal
  
  

-Ajay

[Reilly Grant]

In https://github.com/w3c/compute-pressure/issues/14 an engineer from Zoom expressed interest in this feature. Do you know if Zoom or any of the other developers mentioned in the TAG review have deployed an experiment using this Origin Trial and if so have they been able to confirm the expected improvement?

WebKit's position expresses skepticism that applications responding to these signals will actually result in an overall improvement in user experience. I would like to see feedback from the developers who have tested this API disproving that position. The OT survey responses that developers will continue to use the API is an indirect signal that that is true but it would be much more convincing to have direct evidence. 

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Vladimir Levin]

Asking as a user, the spec draft recommends that user agents...

... show some form of user-visible notification that informs the user when a pressure observer is active, as well as provides the user with the means to block the ongoing operation ...

 

Do you know if this recommendation has been implemented? Also, is there a permission prompt for this feature?

Thanks!

Vlad

[Kenneth Rohde Christiansen]

This has not been implemented, no.

I believe this was discussed with the Google UX team. Maybe Ajay can
follow up with them?

[Andreas Bovens]

On Wednesday, March 6, 2024 at 6:53:40 PM UTC Reilly Grant wrote:

In https://github.com/w3c/compute-pressure/issues/14 an engineer from Zoom expressed interest in this feature. Do you know if Zoom or any of the other developers mentioned in the TAG review have deployed an experiment using this Origin Trial and if so have they been able to confirm the expected improvement?

Here at Whereby, we’ve been experimenting with this Origin Trial and have found it to be valuable.

• We’ve been logging occurrences of high CPU pressure (powered by the OT) during Whereby calls in our internal meeting analysis tools, and have found there is a correlation between these events and perceived media quality (audio/video quality drops, etc.). As a result, we plan to surface these CPU spikes in our external customers’ session insights timelines as well, as they are useful context to have when diagnosing particular issues.
   
• We’re close to releasing a new feature: a "meeting diagnostics" panel that displays real-time CPU usage (powered by the OT), along with video and audio transmission quality, during sessions. This tool aims to enable participants to take the appropriate action to maintain audio quality, such as opting for audio-only mode. In a next phase, we aim to develop an algorithm that combines these CPU/audio/video inputs, so as to automatically select the most suitable communication mode.
  

We are keen to see the Compute Pressure API ship!

Best,

Andreas

[Philip Jägenstedt]

Thank you for sharing aggregated feedback, Ajay.

I couldn't find any discussion about sampleRate vs an interval, so I've filed https://github.com/w3c/compute-pressure/issues/253 with all the precedent for and against that I could find.

Kenneth, Arnaud, can you look into this and decide whether to rename or not?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/36e63e65-9326-4f5f-8fa0-b1e512e53394n%40chromium.org.

[Kenneth Rohde Christiansen]

Thanks Philip!

I commented on the issue you created, but I don't feel strongly about
any of the options as it is easy to convert from one to the other. We
looked at it before and decided to not change it then, but we are open
to good arguments so please chime in.

[Philip Jägenstedt]

Thanks Kenneth!

Given the feedback from Whereby (thanks Andreas!) and the aggregated origin trial feedback that Ajay shared I think we should ship this, just a few more notes/questions.

Please do what you think makes sense with the naming. I think there's a case for renaming, but it's up to you and doesn't block shipping IMO.

Taking a look at https://wpt.fyi/results/compute-pressure I see that most of the tests are tentative. Should they still be, or why doesn't the spec cover so much of the behavior?

[Raphael Kubo da Costa]

Philip Jägenstedt <foo...@chromium.org> writes:

> Taking a look at https://wpt.fyi/results/compute-pressure I see that most
> of the tests are tentative. Should they still be, or why doesn't the spec
> cover so much of the behavior?

As someone who reviewed most of the test: I think "tentative" should be
removed from the file names. The original web tests from years ago [1]
were tentative, so we ended up keeping it for all tests that were added
later as an oversight.

[1] https://github.com/web-platform-tests/wpt/commit/5bf9aca03e4c10345c0d023d1864ac9c6c7957e1

With that said, I think the current coverage is quite good (and what we
can't test in WPT is being tested in services_unittests), was there
anything that indicated that coverage was not ideal or is it because of
the presence of "tentative" in the test names?

[Philip Jägenstedt]

I just wondered why so many tests are tentative. It easily happens that tests are left tentative longer than needed, and it sounds like that's the case here.

Taking a closer look, I think it's really because the tests depend on MojoJS, and if we exclude tentative tests only surface level tests remain.

Compute Pressure tests were mentioned in https://github.com/web-platform-tests/rfcs/issues/172 and my read is that Apple and Mozilla would prefer that we not upstream tests that depend on unspecified testing APIs. I'd suggest one of the following:

• Define a WebDriver Classic endpoint in the style of https://w3c.github.io/sensors/#automation
• Define a WebDriver BiDi command in the style of https://w3c.github.io/permissions/#automation-webdriver-bidi
• Define a testing API in the style of https://wicg.github.io/webusb/test/
• Move the tests to wpt_internal (meaning much fewer shared tests for a second implementer)

What do you think makes the most sense here?

[Raphael Kubo da Costa]

Philip Jägenstedt <foo...@chromium.org> writes:

> Taking a closer look, I think it's really because the tests depend on
> MojoJS, and if we exclude tentative tests

> <https://wpt.fyi/results/compute-pressure?label=master&label=experimental&aligned&q=%21is%3Atentative>

> only
> surface level tests remain.
>
> Compute Pressure tests were mentioned in
> https://github.com/web-platform-tests/rfcs/issues/172 and my read is that
> Apple and Mozilla would prefer that we not upstream tests that depend on
> unspecified testing APIs.

Thanks for bringing this up, I wasn't aware of this discussion in the
rfcs repository. We went with MojoJS because it was the easiest option
while the API and the implementation were changing rapidly. And because
in the past (for better or worse) other APIs depending on MojoJS had
been added to WPT, we just went ahead with what felt like the usual and
landed those tests in WPT too.

> I'd suggest one of the following:
>

> - Define a WebDriver Classic endpoint in the style of
> https://w3c.github.io/sensors/#automation
> - Define a WebDriver BiDi command in the style of
> https://w3c.github.io/permissions/#automation-webdriver-bidi
> - Define a testing API in the style of
> https://wicg.github.io/webusb/test/
> - Move the tests to wpt_internal (meaning much fewer shared tests for a

> second implementer)
>
> What do you think makes the most sense here?

The quickest solution is to just move all web tests that currently
depend on MojoJS to wpt_internal.

A WebDriver Classic endpoint is what we'd need next. We've got
experience with that (in fact, in the past few months I've added
WebDriver endpoints to the Generic Sensor and Device Orientation specs
and removed the dependency that their web tests in WPT had on MojoJS),
and there are plans to add some DevTools support for Compute Pressure in
the not too distant future that would help with it too.

Would going with the options above block the shipping process somehow?
The current web tests work and offer good coverage of the
implementation, they just aren't as interoperable as they should.

[Philip Jägenstedt]

LGTM1

I don't want to block shipping on this :)

LGTM assumes that https://github.com/w3c/compute-pressure/issues/253 is resolved in some way, I'm not insisting on any particular outcome. And that tests are moved into wpt_internal some time soon, but that could happen after branch point.

It would be fantastic if you also want to do the work to allow adding the tests back to WPT, but at present we're not requiring shared tests when it requires new test infrastructure. I would certainly like to move in that direction, but would like to wait for WebDriver BiDi integration into testharness.js before that feels like a reasonable ask for all or most features.

[Yoav Weiss (@Shopify)]

LGTM2 given the strong developer feedback and plans for use in user-facing features.

--

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.

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

[Arnaud Mandy]

Shipping of Compute Pressure API has been changed from M124 to M125.
Today is M124 branching and we are not fulfilling all the requirements for shipping given the ongoing discussions, the filed issue, and one missing LGTM. 
We are still actively working on the items just mentioned to see Compute Pressure API shipping in M125.

Br,
Arnaud

On Tuesday, March 5, 2024 at 1:57:31 PM UTC+2 Arnaud Mandy wrote:

Contact emails

kenneth.r.c...@intel.com, arnaud...@intel.com, wei4...@intel.com, raphael.ku...@intel.com

Explainer

https://github.com/w3c/compute-pressure/blob/main/README.md

Specification

https://www.w3.org/TR/compute-pressure

Summary

The Compute Pressure API offers high-level states that represent the pressure on the system. It allows the implementation to use underlying hardware/platform metrics to inform the API users of possible stress (high CPU load at the moment) on the system and consequently take the corrective actions needed.

“Pressure” is a generic term by design – at the moment it is calculated based on CPU load, but future plans include using signals from temperature and battery status, for example.

https://developer.chrome.com/docs/web-platform/compute-pressure/

Blink component

Blink>PerformanceAPIs>ComputePressure

Search tags

compute pressure

TAG review

spec review: https://github.com/w3ctag/design-reviews/issues/795

wide review tracker: https://github.com/w3c/compute-pressure/issues/177

TAG review status

Issues addressed

Chromium Trial Name

ComputePressure

Origin Trial documentation link

https://developer.chrome.com/docs/web-platform/compute-pressure/

Origin Trials history

The first Origin Trial was run between M92-94.

The Compute Pressure API was widely redesigned after this OT to resemble existing observer-based web APIs and also to provide better privacy and security guarantees after discussions with PING.

The second Origin Trial took place during M115-M120.

During this origin trial we realized that the full capacity of the API couldn’t be tested due to a lack of support for third-party tokens. An

Origin Trial extension was necessary until M123.

Risks

Interoperability and Compatibility

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/521)

WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html) This issue has been taken into account: https://github.com/w3c/compute-pressure/issues/24

Web developers: Positive (https://github.com/w3c/compute-pressure/issues/14)

Other signals:

Security

https://github.com/w3c/compute-pressure/issues/79

WebView application risks

No

Debuggability

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

No,
Windows, Linux, ChromeOs, Mac.

Support on Android (incl. Android WebView) has been deprioritized as there is no current way to access the telemetry needed after Android 11, and the current partners we are engaging with have no need as they are using native solutions on Android at this point.

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/compute-pressure?run_id=5116280230641664

The wpt.fyi results are flaky due to WPT bug 44438

DevTrial instructions

https://github.com/w3c/compute-pressure/blob/main/HOWTO.md

Flag name on chrome://flags

see https://github.com/w3c/compute-pressure/blob/main/HOWTO.md

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1067627

Launch bug

https://crbug.com/1173266

Sample links

https://w3c.github.io/compute-pressure/demo

Estimated milestones

OriginTrial desktop extension	123
OriginTrial desktop last	118
OriginTrial desktop first	115
OriginTrial desktop last	94
OriginTrial desktop first	92
DevTrial on desktop	109

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5597608644968448

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/LTIRZ24C5Os/m/BPSeJ8y0BwAJ

 Ready for Trial: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/-1ciwdn23J4

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/QfJ4pngu3gc

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/HzVV-sM97T0

Intent to Extend Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/s83S7wXxa6E/m/AjvsIJxmAQAJ

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

LGTM3

--

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7c4c2393-3c8c-4257-88f2-cf351e74a650n%40chromium.org.

[Philip Jägenstedt]

Hi Arnaud,

I have a followup question about this. I assumed that the feature wouldn't be enabled on Android, but judging by Chromium source and wpt.fyi test results, at least the API surface is exposed:

https://wpt.fyi/results/compute-pressure/idlharness.https.any.html?label=master&label=experimental&product=chrome&product=chrome_android&aligned

What will be the behavior on Android, will the API appear to work but never invoke the observer callback? If so, would it make sense to disable the feature on Android instead?

Best regards,

Philip

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8f%2BaUZAMx1qiGv2CxBXY1vcqQ1Ot%3DU63My98gem9x3_w%40mail.gmail.com.

[Arnaud Mandy]

Philip,

Thanks for the follow up.
Yes, you are correct! 

I ll file a bug and propose a fix (disabling feature on Android).

Arnaud.

[Raphael Kubo da Costa]

Op 17-05-2024 om 16:59 schreef Philip Jägenstedt:

> What will be the behavior on Android, will the API appear to work but
> never invoke the observer callback? If so, would it make sense to
> disable the feature on Android instead?

I'd just like to check if there's a general guideline for cases like this.

On Android, calls to observe() will reject with NotSupportedError, which
I thought was fine. Does it mean that when a given API is not expected
to be implemented for a certain OS it is better to avoid exposing its
surface altogether, even if the binary size doesn't change as a result?

[Philip Jägenstedt]

I don't think we have written guidelines, but my rule of thumb would
be to hide the whole API. This is what happens when there's a runtime
flag in the IDL and it's enabled for some platforms and disabled for
others. Exposing the API makes feature detection harder, and makes
idlharness.js tests pass for a feature that doesn't work.

An exception to this would be when some API is supported on most/all
browsers and not exposing it might be a site compat risk. But this
isn't the case when we first ship a feature, it's something we might
see when wanting to remove an API and outright removal would break too
much.

Best regards,
Philip

[Daniel Herr]

Could someone elaborate on why this won't be implemented for Android? It seems like a very useful thing to have, especially considering that the biggest amount of users with low end hardware who would stand to benefit are on Android.

"Support on Android (incl. Android WebView) has been deprioritized as there is no current way to access the telemetry needed after Android 11, and the current partners we are engaging with have no need as they are using native solutions on Android at this point."

I see a variety of CPU monitoring apps in the Play Store. Could someone test if they work on Android >=12?
Also, how can it be both that new Android versions don't allow access and partners are using native solutions? Why can't Chromium use whatever they are using?

[Kenneth Rohde Christiansen]

To be honest we haven't looked deeply into Android support given we didn't have any active partners for that, and it is not a core platform for our team at Intel.

I did check out apps like AIDA64 and CPU-Z and they report 0% utilization on my Pixel phone. Some apps like "CPU monitor" show utilization but it is all over the place, moves from 100% to 16%, and back to 100% multiples times per second. They might just be looking at the CPU core hertz and considering max frequency to be 100%, which would not be too useful.

I am not an Android expert, so feel free to enlighten me :-)

Cheers,

Kenneth

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/796196c5-2e48-4b04-a2f5-51e17d673df4n%40chromium.org.