Ditto on the question about hotplug. Immediate problem that comes to mind is a web app loaded in power saving mode, followed by the user plugging in a charger.
On Tue, Jul 14, 2026 at 5:58 AM Nikolaos Papaspyrou <[email protected]> wrote: > We have been running an OT since M146: > https://developer.chrome.com/origintrials/#/view_trial/2628413332524105729 > > The chromestatus entry contains more metadata. > There have been 40 registrants, so far, and we haven't had any actionable > or negative feedback. > Alex, did you mean that an additional OT would be beneficial for some > reason? > > Both the explainer and the specification for this API contains code that > illustrates how it can be used to obtain static CPU information, e.g. when > a web app starts. > It is artificial, in the sense that it is not taken from some specific web > app that uses it in production; unfortunately we do not have access to such > code that is publicly available. > Also, this code does not show how to use it in combination with dynamic > CPU information, e.g. with the CPU Pressure API. > IMO, adding such code would only be useful as an example of how to use the > CPU Pressure API and does not fit there. > If, when and how exactly the two APIs should be used in combination > depends a lot on the specific needs of web apps. > Alex, did you have something specific in mind, where showing the > combination of the two APIs would be beneficial? > If so, we can try to add some more artificial code. Again, unfortunately > we do not have access to production code that is publicly available. > > Best regards, > Nikos. > > > On Wednesday, July 8, 2026 at 5:11:07 PM UTC+2 Alex Russell wrote: > >> Hey folks, >> >> Sorry for letting this drag on, but I'm still stuck on seeing some >> example code that shows how this might be used in anger. Are there >> developers who have tried this behind a flag that might be able to weight >> in? And is there any reason not to go to OT if we can't either show how >> this works in practice alongside compute pressure, or is used instead? >> >> Best, >> >> Alex >> On Saturday, June 27, 2026 at 1:47:08 PM UTC-7 Sangwhan Moon wrote: >> >>> One small thing that came to mind is when there is CPU hotplug is >>> involved (e.g. ChromeOS does this for battery saver). >>> >>> It seems like as of today there isn't a way for apps to react when the >>> core count changes by the system - has an event or watcher been considered? >>> >>> Sangwhan Moon >>> >>> On Jun 26, 2026, at 8:51, Rick Byers <[email protected]> wrote: >>> >>> >>> >>> >>> On Fri, Jun 26, 2026 at 9:16 AM Barry Pollard <[email protected]> >>> wrote: >>> >>>> Look at the Explainer again, I'm not sure how this would be use in >>>>> conjunction with (or in opposition to) Compute Pressure. Can you show >>>>> in code there how they compose or compete? What use-cases benefit from the >>>>> static judgement more than the dynamic one? >>>> >>>> >>>> I don't have code, but I see them as related but different. >>>> >>>> IMHO the Compute Pressure API is about dealing with a system under >>>> stress and backing off non-critical work. >>>> >>>> This CPU Performance API is about setting an initial baseline of what a >>>> system should be able to handle under normal conditions (i.e. don't default >>>> assumptions that a system is under-powered and default to the bare minimum >>>> and make the user perhaps miss out on providing optional, extra >>>> enhancements, but also don't assume it's overpowered and make users turn >>>> off features to get a useable experience). >>>> >>>> Now it's true that the Compute Pressure API *could* be used for the >>>> same reasons as CPU Performance API. But that basically means ramping up >>>> until it hits a pressure point and then backing off. That's effectively >>>> just another form of micro-benchmarking and I think we all understand the >>>> downsides of that. >>>> >>>> I also think this CPU Performance API is a simpler, and more developer >>>> egronomic API than computer pressure, along the lines of Network >>>> Information API and Device Memory API where sites can use these >>>> signals to customize the experience >>>> <https://www.smashingmagazine.com/2022/03/signals-customizing-website-user-experience/#device-capability-signals> >>>> *upfront* (for example providing a more stripped down experience for >>>> lower-powered devices). The Compute Pressure API is more about >>>> *reacting* to continual signals in a real-time fashion, so I'd see it >>>> as a more advanced use case for real time systems (video conferencing, >>>> video games). I don't think you want to remove features already loaded due >>>> to Compute Pressure (for example, you wouldn't switch already-loaded hi-res >>>> images to lower resolution images based on CPU pressure), just lower/pause >>>> continually processing processes like video or background calculations. >>>> >>>> Would sites use both? Maybe. But as I say, I think the Compute Pressure >>>> API is a more advanced API. >>>> >>> >>> Thanks Bary, this was exactly my thinking too - depending on your use >>> case you'd want either static (eg. UX that is jarring to change) or dynamic >>> (more advanced, good for anything that really needs to adapt over time). I >>> still think we COULD show an example of a dynamic system which bootstrapped >>> itself using the static value, but I'm not personally aware of any >>> developer who wants to do that, so it might be entirely artificial. For >>> problems where the UX is amenable to a dynamic system, wouldn't I want to >>> just always go for the max utilization and back off under pressure, rather >>> than try to set some artificial ceiling? >>> >>> Nikos, WDYT? Can you ask any of your known OT users for this API whether >>> they are using it in conjunction with dynamic signals, or whether they have >>> features effectively split into those which are dynamic vs. those that are >>> static? For example, the explainer talks about setting initial video >>> resolution, frame rate and features for a video chat app. Features seems >>> clearly static to me (don't want background blur turning off and on based >>> on CPU load). But what about framerate and video resolution? Would these >>> generally only be changed by user action (manually choosing a higher >>> resolution), by other dynamic signals (like dropped frames), or also by CPU >>> pressure? >>> >>> On Mon, 22 Jun 2026 at 16:02, Rick Byers <[email protected]> wrote: >>>> >>> Thanks everyone for the input and offer of support! Note that Nikos is >>>>> OOO this week so we should not expect responses from him until next week. >>>>> I >>>>> believe the team will likely postpone this feature to M152 to ensure >>>>> there's adequate time to engage with this debate and make any necessary >>>>> adjustments. But note the OT ends in 151 so IMHO we should not let this >>>>> slip past M152 without a very good reason. >>>>> >>>>> Regarding the interoperability concern >>>>> <https://github.com/WICG/cpu-performance/issues/2>, I also built a JS >>>>> reference implementation derived from the Chromium impl and proposed >>>>> contributing it to the WICG >>>>> <https://github.com/WICG/cpu-performance/pull/12>, along with a little >>>>> demo page <https://rbyers.github.io/cpu-performance/demo.html>, and >>>>> possible >>>>> spec additions <https://github.com/WICG/cpu-performance/pull/13>. I >>>>> suggest we give the standards debate a couple weeks to play out in the >>>>> WICG >>>>> repo + TAG thread. Then, depending on the outcome, API owners can evaluate >>>>> whether to ask the team to move their implementation into an independent >>>>> open source repo. IMHO if the spec ends up reasonably precisely defining >>>>> the algorithm, there's no reason to request any changes in Chromium's >>>>> implementation strategy. >>>>> >>>>> Rick >>>>> >>>>> On Mon, Jun 22, 2026 at 5:48 AM Thomas Steiner <[email protected]> >>>>> wrote: >>>>> >>>> I know that the Web AI community are very interested in finding out if >>>>>> a given device can run an AI model. In the native world, there are tools >>>>>> like llmfit <https://github.com/AlexsJones/llmfit>. I recently >>>>>> compared what they can obtain with what is available via Web APIs. >>>>>> >>>>>> *llmfit:* >>>>>> >>>>>> <Screenshot 2026-06-12 at 12.31.54.png> >>>>>> >>>>>> *Web APIs:* >>>>>> >>>>>> <Screenshot 2026-06-12 at 12.35.17.png> >>>>>> >>>>>> >>>>>> - Hardware concurrency shows 14 cores, paired with other info >>>>>> like OS, you can pretty accurately tell the CPU. >>>>>> - Device memory shows a capped value of 32 GB, but I actually >>>>>> have 48, and it doesn't give you the currently free RAM. >>>>>> - GPU adapter info seems on par, and I think there could be some >>>>>> info you could deduce about available RAM by looking in the max >>>>>> buffer size >>>>>> and additional out-of-bounds knowledge based on the vendor. >>>>>> >>>>>> Happy to put you in contact with the people at Hugging Face I'm >>>>>> talking to. They are interested in the API for sure. >>>>>> >>>>>> Cheers, >>>>>> Tom >>>>>> >>>>>> On Sat, Jun 20, 2026 at 1:25 AM Rick Byers <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> I am personally convinced of the use case's importance and Nikos's >>>>>>> responses to the TAG feedback. In addition to the linked Adobe >>>>>>> <https://github.com/WICG/cpu-performance/issues/6> and Figma >>>>>>> <https://github.com/WICG/proposals/issues/253#issuecomment-3719833708> >>>>>>> support, Josh Comeau's comments on the I2P >>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/8y-EauEeWWE/m/ghE0ByYaCAAJ> >>>>>>> are notable. >>>>>>> >>>>>>> While it's quite dated now, this all aligns with my personal >>>>>>> experience working on mobile GMail. We essentially had a database >>>>>>> mapping >>>>>>> heuristic signals (like precise device model strings in the UserAgent >>>>>>> header) to higher level concepts of device capability (similar to what >>>>>>> Facebook >>>>>>> described around that time >>>>>>> <https://engineering.fb.com/2014/11/06/android/year-class-a-classification-system-for-android/>). >>>>>>> Then, we'd serve our best guess of a bundle of html/js in the initial >>>>>>> HTTP >>>>>>> response based on these heuristics (with a selection of features enabled >>>>>>> which we believed would work well for the user). When people argued that >>>>>>> relying on such heuristics was "wrong", we would cringe at their lack of >>>>>>> pragmatism and connection to the real-world tradeoffs involved in >>>>>>> delivering a top-tier web app which refused to compromise on user >>>>>>> experience. Of course that team eventually (very reluctantly) gave up on >>>>>>> the web, deciding it was too hard to fight things like this relative to >>>>>>> native mobile platforms where they faced no such headwinds. >>>>>>> >>>>>>> This proposed API is a HUGE improvement for browser >>>>>>> interoperability over the approach we used in GMail, since it was >>>>>>> virtually >>>>>>> impossible for a browser/device maker to tell what signal we were using >>>>>>> on >>>>>>> our server to determine the quality of experience we served them. I >>>>>>> would >>>>>>> expect such heuristics are still relied upon across sophisticated web >>>>>>> apps. >>>>>>> Developers of such sophisticated web apps have no reason to talk >>>>>>> publicly >>>>>>> about how they optimize user experience, since such heuristics are >>>>>>> generally frowned upon yet also a competitive differentiator for the >>>>>>> best >>>>>>> of the web. >>>>>>> >>>>>>> My only concern with this intent (especially after reflecting >>>>>>> <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/mycizSF0lnQ?e=48417069> >>>>>>> on my handling of the prompt API intent) is whether it meets our bar for >>>>>>> establishing "plausible interoperability". If I were working on Firefox >>>>>>> and >>>>>>> wanted to ensure an Adobe or Figma web app got the same quality level of >>>>>>> experience as Chrome thanks to this API, I'm pretty sure I would want to >>>>>>> just copy the Chromium algorithm >>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:content/browser/cpu_performance/cpu_performance.cc?q=cpu_performance.cc&ss=chromium> >>>>>>> exactly rather than risk doing something different. If we expect that to >>>>>>> happen, then I think the burden should be on us to make that easy, e.g. >>>>>>> by >>>>>>> either: >>>>>>> >>>>>>> 1) Moving our core algorithm into an open-source repo independent >>>>>>> from Chromium, intended to be easy for other browser engines to consume >>>>>>> and >>>>>>> keep up-to-date, OR >>>>>>> >>>>>>> 2) Encoding the algorithm we're using directly into the spec >>>>>>> (perhaps via a reference implementation as is done for other specs like >>>>>>> WASM). Ensuring this stays in sync with Chromium could be a pain, but >>>>>>> maybe >>>>>>> some declarative data table could be used to drive the algorithm? >>>>>>> >>>>>>> If all other engines oppose this capability in any form, it's >>>>>>> probably not worth doing this work now for zero tangible benefit. >>>>>>> Instead perhaps we should commit to taking one of the above paths should >>>>>>> another implementation come along in the future and request it? WDYT? >>>>>>> >>>>>>> Rick >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 18, 2026 at 12:03 PM Nikos Papaspyrou < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> On Wednesday, June 10, 2026 at 5:28:38 PM UTC+2 >>>>>>>> [email protected] wrote: >>>>>>>> >>>>>>>>> I saw there were some open comments/questions on the TAG review >>>>>>>>> thread https://github.com/w3ctag/design-reviews/issues/1198 -- it >>>>>>>>> would be great if you could respond there so that review might reach >>>>>>>>> some >>>>>>>>> conclusion. >>>>>>>> >>>>>>>> >>>>>>>> The comments and questions on the TAG review thread have now been >>>>>>>> answered. >>>>>>>> >>>>>>>> On Wed, Jun 17, 2026 at 8:59 PM Reilly Grant <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Alex, >>>>>>>>> >>>>>>>>> In my experience speaking with developers, the issue is that even >>>>>>>>> with logic to make a dynamic judgement (by using the Compute Pressure >>>>>>>>> API >>>>>>>>> or other feedback such as dropped frames) the site still needs to >>>>>>>>> decide >>>>>>>>> what to load first. Consider a developer looking to run an ML model >>>>>>>>> on-device: They may have 3 different models requiring progressively >>>>>>>>> higher >>>>>>>>> compute capabilities but offering similar improvements in quality. >>>>>>>>> Since >>>>>>>>> each model takes time to load, ideally you would load the correct one >>>>>>>>> first >>>>>>>>> most of the time. This API can help with that. It's still just an >>>>>>>>> assumption so other dynamic signals are still necessary. >>>>>>>>> >>>>>>>>> Nikos, if this matches your experience can you add something like >>>>>>>>> my explanation above to the explainer? >>>>>>>>> On Wed, Jun 17, 2026 at 8:13 AM Alex Russell < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Thanks for all of this, Nikos. >>>>>>>>>> >>>>>>>>>> Look at the Explainer again, I'm not sure how this would be use >>>>>>>>>> in conjunction with (or in opposition to) Compute Pressure. Can you >>>>>>>>>> show in >>>>>>>>>> code there how they compose or compete? What use-cases benefit from >>>>>>>>>> the >>>>>>>>>> static judgement more than the dynamic one? >>>>>>>>>> >>>>>>>>> >>>>>>>> Thank you Alex and Reilly! Reilly's explanation matches indeed the >>>>>>>> feedback from our partners. >>>>>>>> I added a paragraph to the "Motivating use cases" section in the >>>>>>>> explainer, to make this more prominent. >>>>>>>> Until the PR is merged, you can read it here: >>>>>>>> https://github.com/WICG/cpu-performance/pull/10/changes >>>>>>>> I hope that this addresses both Alex's comments and similar >>>>>>>> comments on the TAG review thread. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Nikolaos Papaspyrou >>>>>>>> >>>>>>>> Software Engineer >>>>>>>> >>>>>>>> [email protected] >>>>>>>> >>>>>>>> >>>>>>>> Google Germany GmbH >>>>>>>> Erika-Mann-Straße 33 80636 München >>>>>>>> >>>>>>>> >>>>>>>> Geschäftsführer: Paul Manicle, Liana Sebastian >>>>>>>> >>>>>>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>>>>>> >>>>>>>> Sitz der Gesellschaft: Hamburg >>>>>>>> >>>>>>>> >>>>>>>> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise >>>>>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes >>>>>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich >>>>>>>> bitte >>>>>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This e-mail is confidential. If you received this communication by >>>>>>>> mistake, please don't forward it to anyone else, please erase all >>>>>>>> copies >>>>>>>> and attachments, and please let me know that it has gone to the wrong >>>>>>>> person. >>>>>>>> >>>>>>>> -- >>>>>>>> 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 [email protected]. >>>>>>>> To view this discussion visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMHN%3DHy3Cqd%2BMX%3DB%3Dy7%2BWwafkiBFCB0zDXj4iRGKt0qmeWerRg%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMHN%3DHy3Cqd%2BMX%3DB%3Dy7%2BWwafkiBFCB0zDXj4iRGKt0qmeWerRg%40mail.gmail.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 [email protected]. >>>>>>> To view this discussion visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8i6a1a-fz8S7%3DCHCSfU1gB%2B9ij1eU7y9gaKOjjqj%2BNxg%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8i6a1a-fz8S7%3DCHCSfU1gB%2B9ij1eU7y9gaKOjjqj%2BNxg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, >>>>>> toot.cafe/@tomayac) >>>>>> >>>>>> Google Spain, S.L.U. >>>>>> Torre Picasso, Pl. Pablo Ruiz Picasso, 1, Tetuán, 28020 Madrid, Spain >>>>>> >>>>>> CIF: B63272603 >>>>>> Inscrita en el Registro Mercantil de Madrid, sección 8, Hoja >>>>>> M-435397 Tomo 24227 Folio 25 >>>>>> >>>>>> ----- BEGIN PGP SIGNATURE ----- >>>>>> Version: GnuPG v2.4.8 (GNU/Linux) >>>>>> >>>>>> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck >>>>>> 0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181. >>>>>> ----- END PGP SIGNATURE ----- >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "blink-dev" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/a/chromium.org/d/topic/blink-dev/igPwzkxhQtk/unsubscribe >>>>> . >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> [email protected]. >>>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY90H6SuPm0JokoOY%2BHBtVUkC3YBSzYK1bS9%3D7%2BVQk%3DtNQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY90H6SuPm0JokoOY%2BHBtVUkC3YBSzYK1bS9%3D7%2BVQk%3DtNQ%40mail.gmail.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 [email protected]. >>> >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-AWVyD5iR3HXSftNrx-HnZBy%2BJwbZb63NOpqnXELyUjA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-AWVyD5iR3HXSftNrx-HnZBy%2BJwbZb63NOpqnXELyUjA%40mail.gmail.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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOZWpL6pYH6Y6zdYmRoYg_7WqqcJ4U3L9qtN1BHcKh9ReL8KLw%40mail.gmail.com.
