Re: [w3ctag/design-reviews] Compute Pressure API (#621)

We reviewed this during breakouts this week. Since all use cases listed relate to web applications responding to high load, we are wondering if a simpler, less granular, more high level API would address these use cases equally well, without the added complexity of specific thresholds, different for CPU utilization and CPU speed. See [Prefer Simple Solutions](https://w3ctag.github.io/design-principles/#simplicity).

If not, it would be good to show use-cases where this is not the case. We assume the reason might be to know well ahead whether you are about to get throttled and it is less interesting knowing when you are being throttled. Is that correct?

We understand that all speeds are being rescaled to a percentages, instead of revealing actual top speeds etc which really helps with privacy, so we welcome that.

In terms of the proposed API, please note that all other observers on the Web Platform today use `observer.observe()` instead of `observer.start()`. Also, while it's good that debugging use cases were considered, we think that a test mode would be more appropriate as a browser dev tools switch instead of part of the API surface. 

The spec has to handle heterogenous computing where the CPU has different kinds of cores (ARM BIG.little, Intel Alder Lake). The software/hardware scheduler can move workloads (such as browser process) to another core with different characteristics, like you might be about to max out the little cores, then you are moved to another core with plenty of performance budget left. This may lead to confusing numbers when it is expressed as a single scalar.

There are other places on the web platform where you might get throttled as if you are a background tab. It this only for visible focused documents, or similar?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/621#issuecomment-824144168