Proposed investigation / demo: Compute Pressure API

[KaliedaRik]

Proposal
The new Compute Pressure API is being developed as a way to check on CPU usage (at a very wide granularity, to prevent fingerprinting) and inform the site when that usage changes:

The Compute Pressure API's goal is to prevent, rather than mitigate, bad user experience in the web app itself and also for the user's device to not become too hot, too loud, or to drain the battery at an unacceptable rate.

The Compute Pressure API exposes high-level pressure states which abstract away complexities of system bottlenecks that cannot be adequately explained with low-level metrics such as processor clock speed and utilization. In fact, metrics for CPU utilization are often misleading. Therefore, the Compute Pressure API uses human-readable pressure states with the following semantics: "nominal"; "fair"; "serious"; "critical"

The contributing factors (that is, the underlying system metrics) for the pressure states above are not defined by the specification and can vary depending on the underlying hardware and platform behavior. However, the specification requires that the change in contributing factors must be substantial to avoid flip-flopping between states. This means you can expect the API to not report different states overly often as they aren't responding to just one fluctuating system metric.

On the surface this looks like a useful development: canvas elements and their associated code can become very CPU-compute-heavy, thus having a way to identify when a web page is putting the CPU under pressure, and available hooks to allow canvas developers to define how to alter the code running in a canvas element in the browser viewport to lessen that pressure, feels very attractive!

Risks

• The API is marked as experimental, thus could change substantially as development/implementation of the API progresses
• Only supported by desktop Chrome (Nov 2024); Firefox seem like they may support it; no signal from Safari to date.