I believe it should |result|, not |return| below
https://github.com/WICG/compute-pressure/blob/75052b4fd3f1ce425d61fe85d14b1b3d4ff59408/index.html#L514

This allows to differentiate what target has had pressure change

It would be very helpful to know current browser process (tab) contribution into the total CPU load.
For example, I have a powerful machine, I am in the video conference, and also I run chromium build. CPU becomes 100% busy, but it does not make sense to reduce number of video feeds in the conference, as this will not save any visible CPU amount - most CPU is taken by build process.
In the video conference code I would analyze current process contribution, and if it is less than lets say 50%, I would avoid any CPU saving activities.

When you handle something like critical pressure, you will need to do less to attempt to exit the state, but you don't always know that doing a bit less is enough to get out of the critical state. Additionally due to thermals etc., doing less might not be reflected immediately.

For this reason, you probably want to keep checking every few seconds (or say half a minute - depending on state) if your change was sufficient or whether you need to do more. An example could be cutting a concurrent video stream from a conference call at each interval while still in the undesirable state.

We have hear before that some prefer to only get events when the state actually changes, but in my own prototype I preferred getting notified at a certain interval and ASAP when a state changed.

You can build such infrastructure yourself on top of the existing specification but it is a bit complex

Here is one way to do it using an async pattern - without special helpers in JS this becomes quite hard to do yourself

Helper:

// Utility: A Promise that is also an Iterable that will iterate
// at a given interval until the promise resolves.

class IteratablePromise extends Promise {
  #interval;
  #fallback;

  constructor(fn, interval, fallbackValue) {
    super(fn);
    this.#interval = interval;
    this.#fallback = fallback;
  }

  async* [Symbol.asyncIterator]() {
    let proceed = true;
    this.then(() => proceed = false);

    yield this.#fallback;

    while (proceed) {
      let value = await Promise.any([
        this,
        new Promise(resolve => setTimeout(resolve, this.#interval))
      ]);
          
      yield value || this.#fallback;
    }
  }
};

// Allow to resolve a promise externally by calling resolveFn
let resolveFn = null;
function executor(resolve) {
  resolveFn = value => resolve(value)
}

async function lowerStreamCountWhileCritical() {
  let streamsCount = getStreamsCount();
  let iter = new IteratablePromise(executor, 30_000, "critical");

  for await (const state of iter) {
    if (state !== "critical" || streamsCount == 1) {
      break;
    }
    setStreamsCount(streamsCount--);
  }
}

function pressureChange(entries) {
  for (const entry of entries) {
    if (resolveFn) {
      resolveFn(entry.state);
      resolveFn = null;
      continue;
    }

    if (entry.state == "critical") {
      lowerStreamCountWhileCritical();
    }
  }
}

const observer = new ComputePressureObserver(pressureChange);
observer.observe();

A much simpler option would be to have the callback being called at an interval that is user configurable, and having it being called even earlier if the state actually changes (and the system polls at a higher frequency)

This is much simpler:

let timerId = -1;
function pressureChange(entries) {
  clearTimeout(timerId);

  const lastEntryArray = [entries.at(entries.length - 1)];
  timerId = setTimeout(pressureChange.bind(this, lastentryArray), 30_000);


  for (const entry of entries) {
    if (entry.state == "critical") {
      let streamsCount = getStreamsCount();
      setStreamsCount(streamsCount--);
    }
  }
}

const observer = new ComputePressureObserver(pressureChange);
observer.observe();

I suggest we allow configuring this behavior simply by the options dict to observe() or the like

Simply something like the following

// Default: Always call as soon as a state change is observed
observer.observe({ immediate: true })

 // Generally call the callback at a declared interval, but immediately if state changes
observer.observe({ interval: 30_000, immediate: true })

// Always call given an interval of 2 sec
observer.observe({ interval: 2000, immediate: false }) 

Spec has been recently updated with a new requestPermission() method. It would be nice to have JS examples in the spec AND the readme file

Feature request from Zoom:

As you can add a callback that stores the current value, you can easily implement a querying method yourself, so adding this doesn't effect privacy or security further. Additionally, existing observers have this ability function as the takeRecords(); method.

https://w3c.github.io/performance-timeline/#dom-performanceobserver-takerecords
https://dom.spec.whatwg.org/#dom-mutationobserver-takerecords
https://www.w3.org/TR/intersection-observer/#dom-intersectionobserver-takerecords

Find the right hooks to make sure we inform the platform collector when workers are unloaded

Similar IntersectionObserver issue: w3c/IntersectionObserver#64

Our observers are conceptually attached to the document (not a DOM node or other JS object), so there's no natural place to "hang" ownership off of.

Here are the options I see.

1. The observer conceptually hangs off of the Document / global object. Downsides:
   a. If the ComputePressureObserver JS object is garbage-collected, there's no way to stop the observer. It will keep the listeners alive (normal for an EventHandler, afaik) and invoke them until the user navigates away from the page.

2. The observer is owned by the ComputePressureObserver JS object. Downsides:
   a. Garbage collection can be observed by JS (events stop getting dispatched).
   b. Less consistent behavior, probably more difficult for developers to debug.

https://wicg.github.io/compute-pressure/#notify-observers seems to notify all observers of all types when invoked, and it's not clear if that's desired. In other words, should an observer started via observe('cpu') also receive updates for GPUs?

@beaufortfrancois

takeRecords() is a part of the API, and should be documented with an example.

From @beaufortfrancois:

Another example where unobserve() is used would be useful as well. disconnect() seems to be the same with only one observer. Then an example with multiple observers would be nice.

How should implementations handle values that exactly equal the quantization thresholds?

For example, the CPU utilization thresholds [0.2, 0.5, 0.8] will create the intervals [0, 0.2], [0.2, 0.5], [0.5, 0.8] and [0.8, 1]. If the measured CPU utilization is exactly 0.5, would that be quantized to 0.35 (for the interval [0.2, 0.5]) or 0.65 (for the interval [0.5, 0.8])?

(Yes, the current explainer and samples are intentionally vague, because I didn't have a good answer.)

Before we had algos consider CPU clock speed and utilization directly, but we cannot do this anymore

Broken out from #14

From Zoom:

we would like the api could be workable even if the tab is inactive or minimized. We have a use case about desktop sharing.

This of course affects privacy so we will see if we need to add certain restrictions in order to make this work., like we could make it work only for focused tabs (like currently implemented, I believe) but allow it also when a tab is currently sharing content using the APIs allowing for that.

We need to look into this. We currently use agents, but I don't think we need to

ComputePressureUpdateCallback takes two arguments, but all the examples in the spec only make use of the first one, records. It'd be good to have some example showing how the second argument, observer, is used, especially in light of the changes landed in #56.

Victor is unlikely to be contributing to the spec work going forward, so should be pulled off the active editor list.

@pwnall - speak up if you disagree!

Step 3 of https://wicg.github.io/compute-pressure/#queue-a-computepressureobserver-task says "[=Queue=] a [=task=] [...]", which is not very helpful:

• It should at least refer to "[=Queue a task=]" instead of referring to Infra's "Queue" definition and HTML's "task" definition.
• Even then, it needs to pass additional parameters to the "queue a task" algorithm.

However, it's probably a better idea to invoke the "queue a global task" wrapper algorithm. From https://html.spec.whatwg.org/multipage/webappapis.html#queuing-tasks:

Failing to pass an event loop and document to queue a task means relying on the ambiguous and poorly-specified implied event loop and implied document concepts. Specification authors should either always pass these values, or use the wrapper algorithms queue a global task or queue an element task instead. Using the wrapper algorithms is recommended.

The current API design has a (currently very subtle) avenue for allowing user agents to determine how much entropy they're willing to expose with this feature.

Quantization schemes are expressed as arrays. Web authors are expected to list value thresholds in order of relative importance, and user agents may choose to ignore some of the thresholds.

For example, Chrome's prototype implementation allows 3 thresholds for CPU utilization. A quantization scheme of [0.5, 0.8, 0.3, 0.9, 0.2] will be reduced to [0.3, 0.5, 0.8] (the sorted version of [0.5, 0.8, 0.3]).

The API is very clear that a (main) frame is only allow to specify one set of buckets. How is the API going to enforce this? With the current example, it sounds like I could create multiple observers and hence get arbitrary precision on the values exposed.

No other Observer spec does this, except PerformanceObserver, but that is really not an "option" as its basically additional data given to the callback and not options as supplied by the developer

Conveying a suggestion from @asafyaffe:

One potential extension is to provide developers with additional high-level information regarding the cause of the pressure, if known (i.e. compute, memory, thermals, storage, network etc.). Without this information, developers may need to implement a “trial and error” loop to properly adjust the user experience.

I'd consider this a future enhancement that warrants discussion once the foundational pieces of the high-level API have been established.

According to the spec text below, ComputePressureObserver observe() does not throw when permission is "prompt".
https://github.com/WICG/compute-pressure/blob/75052b4fd3f1ce425d61fe85d14b1b3d4ff59408/index.html#L379

I believe it should be If |permissionState| is not [=permission/granted=], throw {{NotAllowedError}}. as
https://www.w3.org/TR/permissions/#dfn-prompt also exists.

What do you think @kenchris?

This issue is to solicit and track security and privacy review feedback from browser vendors, W3C's Privacy Interest Group, other privacy experts. While these reviews are formally part of the standards track, it is beneficial to conduct such reviews and capture any related feedback as early as possible, including any informal feedback and comments.

To facilitate this process, the Compute Pressure API contributors have proactively completed the Self-Review Questionnaire: Security and Privacy, documented the responses in a separate document and updated the Security and privacy considerations accordingly.

Please note the Compute Pressure API has been recently substantially refactored based on the high-level metrics proposal #24 to address feedback provided in WebKit Request for Position and with consideration for new use cases, web developer ergonomics in addition to privacy and security. To that end, we are in particular interested in browsers vendors' feedback on the security and privacy properties of the new API.

All feedback welcome, including LGTMs and more directional guidance.

• Chrome's security and privacy team #79 (comment)

I think it's fine to move the explainer to the README, so that it's visible on https://github.com/oyiptong/compute-pressure Alternatively, link the explainer from the README so that people don't have to dig through file names to find the explainer.

Though it is unlikely given we rate limit, potentially we could get many items in the QueuedRecords and maybe we should do something like PerformanceObserver:

https://w3c.github.io/performance-timeline/#dfn-dropped-entries-count

To avoid cross origin user tracking, many specs restrict features to active focuses documents (example Generic Sensors).

But for compute pressure, one of the core use-cases is actually to know the CPU pressure while screen sharing to make sure the screen sharing is smooth, and the video streams and effects do not negatively affect the screen sharing. But during screen sharing, it is quite common that the web site/app using compute pressure is not actually focused.

This will require hooks in other specs and we probably need something like a initiator-of-still-active-screensharing-session

@eladalon1983 @riju @fideltian

Hello, we have a web client and PWA version of zoom client. we love to have these kind of features very much. Some use cases i would like to share:

1. To give the better user experience, we could adaptor the vidoe resolution depends on the CPU occupation, especially the initial resolution. But due to privacy, we cannot get the cpu spec. So CPU occupation is also a way. Audio also have similiar use cases as video.
   2) we have some funny features, some of them need lots of computing load. we need to know the CPU occupation and decide the minimal machines to be supported.

And we looked at the APIs we have some feedbacks.

1. The observer mode will return the cpuUtilizationThresholds every 1 second. how about returning only when there is change. otherwise the callback is too often.
2. and provide a API that could be querid by Application at any time. it is to let application to adjust based on the up/down trend of CPU usage.

Another requirement is about implementation.

1. we would like the api could be workable even if the tab is inactive or minimized. We have a use case about desktop sharing.
2. the API could be workable in worker thread as well?

For consistency with Intersection Observer

https://w3c.github.io/IntersectionObserver/#dom-intersectionobserverentry-time

Also consider using their description

The attribute must return a DOMHighResTimeStamp that corresponds to the time the intersection was recorded, relative to the time origin of the global object associated with the IntersectionObserver instance that generated the notification.

As currently specified we differ somewhat from other *Observer's on the platform:

Each instance of the Observer class is constructed with a callback, and optionally with some options to customize what should be observed.

Actually only IntersectionObserver takes options as part of the ctor, all others as part of calls to observe()

Instances begin observing specific targets, using a method named observe(), which takes a reference to the target to be observed. The options to customize what should be observed may be provided here instead of to the constructor. The callback provided in the constructor is invoked when something interesting happens to those targets.

We don't have a special target - we don't allow targetting a specific CPU core or similar. We might allow GPU in the future, so we could make this be an enum instead like "cpu" or "gpu". It might make sense to allow observe to change the options.

Callbacks receive change records as arguments. These records contain the details about the interesting thing that happened. Multiple records can be delivered at once.

Yes, all existing observers do that. That might make a lot of sense for us as well, maybe even with timestamp.

The author may stop observing by calling a method called unobserve() or disconnect() on the Observer instance.

We currently use unobserve() - maybe disconnect() is better and also makes more sense if we allow changing options on the fly.

Looking at examples:

[Exposed=(Window)]
interface ResizeObserver {
    constructor(ResizeObserverCallback callback);
    undefined observe(Element target, optional ResizeObserverOptions options = {});
    undefined unobserve(Element target);
    undefined disconnect();
};

I see that you can observe multiple elements and disconnect stops all observations. Now this makes sense thinking about CPU and GPU etc

    enum ComputePressureTarget { "cpu", "gpu" };

    undefined observe(ComputePressureTarget target, optional ComputePressureObserverOptions options = {});
    undefined unobserve(ComputePressureTarget target);
    undefined disconnect();
};

Optionally, a method may be provided to immediately return records for all observed-but-not-yet-delivered occurrences.

This is the takeRecords() method other observers support. With batching that makes sense supporting

End result:

enum ComputePressureTarget { "cpu", "gpu" };
callback ComputePressureObserverCallback = undefined (sequence<ComputePressureObserverEntry> entries, ComputePressureObserver observer);


[Exposed=Window]
interface ComputePressureObserver {
  constructor(ComputePressureObserverCallback callback);
  undefined observe(ComputePressureTarget target, ComputePressureObserverOptions options = {});
  undefined unobserve(ComputePressureTarget target);
  undefined disconnect();
  sequence<ComputePressureObserverEntry> takeRecords();
};

IntersectionObserver also takes thresholds and actually expose those set on the object:

readonly attribute FrozenArray<double> thresholds;

For error handling, I see that MutationObserver observe() throws TypeError

Picture in picture uses the following terminology:

As one of the unloading document cleanup steps, run the exit Picture-in-Picture algorithm.

Currently we have

If state has not changed since last sample for source, abort these steps.

but now we have factors, we should consider a change in factors as well.

That change is simple to make, but then it might make sense to have an easy way to check the last state and factors - maybe we just add an example

this.lastRecord = records.at(-1); // last item

Now that we use ComputePressureSource as type instead of DomString, we need to adapt the error return to TypeError.

I am running an experiment to measure the client-side CPU load under different video conferencing architectures ( mesh, mixer, SFU etc ). I have set up this on chrome beta with fake streams and have no other program running on this machine( that take significant more power than idle).
When I see my CPU utilization spiking to 100% on large scale video conferences on my system performance monitor, I do not see 100% CPU utilization on the compute API reports. Is it designed to never go above 75%? or I am mssing something ?

For example I have never seen any value go above 75% CPU Utilization and 75 % CPU speed.
1.943 0.75 0.75
1.08 0.75 0.75
1.923 0.75 0.75
2.007 0.75 0.75
2.071 0.75 0.75

Even though CPU is heated immesely and shows ~99% utilization on all cores.
My system's has Intel® Core™ i7-7500U CPU @ 2.70GHz × 4.

As this could be used for identifying the user across multiple origins, we could restrict this to focused browsing contexts. Thus the timestamp is only set when you are focused, otherwise undefined @anssik

Broken out from #14

The observer mode will return the cpuUtilizationThresholds every 1 second. how about returning only when there is change. otherwise the callback is too often.

This should be an easy change and one that I agree with.

From @beaufortfrancois:

They do not tell you anything, however, about whether that API is actually connected to a
real [=platform collector=], whether the [=platform collector=] is collecting real telemetry
readings, or whether the user is going to allow you to access it.

I didn't see in the spec where user could not allow it.

True, we haven't looked into whether we want to guard this behind a permission and where that should be done. Let's discuss that here

ex.

4. Rate-limiting - The user agent notifies the application of changes in the information it can learn (buckets that each aggregated number). Change notifications are rate-limited.

should refer to the section talking about notification frequency @arskama

It is not clear in current spec that ComputePressureRecord is appended to QueuedRecords only when pressure state changes.

Broken out from #14

The spec is written with an obsolete style for method and attribute algorithms, e.g.:

The observe() method, when invoked, MUST run the following step, given the arguments source:

When supportedSources's attribute getter is called, MUST run the following steps:

The more compact modern way is:

The observe(source) method steps are:

The supportedSources getter's steps are:

there is a bug in the algo.

We shouldn't be deleting the whole list of records, only the one from the unobserved source.

It would be nice to understand GPU load as well, as in some cases this is a bottleneck, not a CPU.
For example, when on low notebook in a video conference I screenshare external 4k screen, built-in internal GPU is 50-60% busy, CPU is 30% busy, and everything starts working very slowly - even mouse becomes jerky.

Currently if you are non-focuses (and has no Picture-in-Picture or active screen share) events are not delivered.

But you might have the CP using site in a inactive tab for a long time in which case it makes no sense to keep the platform collector alive. Some browsers (like Chrome) also has the ability to sleep inactive tabs (say after 5 min) so we need to make sure how to handle that and at least to not prevent sleeping the tabs.

The same accounts for bfcache (active vs non active (bfcached) state). Currently we don't deliver events to non active sites (or workers of such sites) but here we might also want some logic to drop the platform collector after a while and reestablish later.

I don't know how much of this should be specced or how, but at least we might need to mention it in non normative text.

@inexorabletash what is your take on this?

https://wicg.github.io/compute-pressure/#platform-primitives says

When a sample is obtained from the platform collector, the user agent MUST run the 8.6.4 Notify Compute Pressure Observers algorithm a per the 8.6 Processing Model

That looks like the wrong algorithm though, as the process through which the sample collected by the platform is added to a ComputePressureRecord, how this ComputePressureRecord is created and how the relevant ComputePressureObserver instances are selected for a given target type are not clear.

I had a chat with @kenchris to propose we revisit both the existing use cases and new use cases that have recently emerged (e.g. #14) to understand whether the current cpuSpeed and cpuUtilization metrics are still the best fit.

I think there's an opportunity to make the API even more ergonomic for web developers who are not experts in computing performance and tuning, and not familiar with related concepts.

I'd like us to assess whether the current use cases could be served with an API that instead of (or in addition to) the current cpuSpeed and cpuUtilization numerical pair would expose a finite set of human-readable compute pressure states that have semantics attached to them.

What I'm interested in exploring is to see if we could raise the level of abstraction (bonus: more privacy-preserving, future-proofing) and make the underlying low-level metrics implementation details. The low-level metrics are harder to explain to web developers and might evolve and in some cases become misleading. I suspect they could be more easily misinterpreted as well.

In this proposal, the low-level metrics to high-level metrics mapping would become an implementation detail, and implementations could also take into consideration other factors that may influence the compute pressure state such as device form factor, thermal budget, and so on when making the decision.

Here's a strawman proposal, plugging into the existing API for illustrative purposes:

enum ComputePressureState { "nominal", "fair", "serious", "critical" };

dictionary ComputePressureEntry {
  ComputePressureState state = "fair";
}

Thoughts?

Related, I think this blog post https://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html arguing CPU utilization metric is misleading should be reviewed. It trigged quite a long discussion among developer audience (also on HN), so there's probably good nuggets of information hidden also in the comments. Leaving it here for interested folks to digest.

[Edit: The state names in the strawman proposal were tweaked a bit. The names should be considered as placeholders to illustrate the idea. These names are subject to change based on feedback received.]

To avoid cross origin user tracking, many specs restrict features to active focuses documents (example Generic Sensors).

But for compute pressure, one of the core use-cases is actually to know the CPU pressure while writing minutes (summary of meeting notes) to make sure the typing experience is smooth, and the video streams and effects do not negatively affect the minute taking.

But during minute taking, it is quite common that the web site/app using compute pressure is not actually focused, as the word processing app is

This will require hooks in other specs and we probably need something like a initiator-of-still-active-picture-in-picture-session

@beaufortfrancois @riju @fideltian

There is no way we know what are the amount of thresholds for each metric.
For example at the moment, it s 1 for CPU speed (2 buckets) and 3 for CPU Utilization (4 buckets)

Should there be a getMaxThreshold() per metric? or a mechanism to tell that the amount of thresholds provided is not suitable?