Further to Rick's answer to Alex, let me address the remaining questions and comments.
The statements of support from Adobe and Figma came before the OT (and before the API was even implemented). The statement from Zoom came during the OT. I think it shows that Zoom would benefit both from static and from dynamic information. It is not clear to me whether they are aware of the Compute Pressure API or if, for some reason, it does not meet their needs. As I understand it, the last example that I included shows the intended use case for both , and that’s my interpretation of how Zoom intends to use it. I am not aware of code using this API that is publicly available at the moment. As I have already mentioned, we have not received any substantial, actionable or negative feedback from partners that participate in the OT. As a result, we have not changed anything in the API itself. Since the first implementation, however, we have introduced all appropriate overrides in Chrome for the value returned by `navigator.cpuPerformance`: a user setting, an enterprise policy, and a DevTools override for simulation and CPU throttling (work in progress). Regarding Sangwhan’s questions about CPU hot plugging, the spec of this API makes it clear that the value returned by `navigator.cpuPerformance` depends on the CPU model and number of cores. If any of these change, e.g., because of hot plugging, it is reasonable to expect that the reported value may change. In fact, the current implementation in Chrome will update the value in new renderers (but it will not change the value in existing ones). If hot plugging represents a significant use case, it may be reasonable to add some sort of observer to the spec, similarly to what the Compute Pressure API does. I will open an github issue to discuss this on the spec. Regarding Sangwhan’s comment about a “web app loaded in power saving mode, followed by the user plugging in a charger”, as we have explained, the API reports static information and should normally have nothing to do with power saving or plugging in the charger — *unless* of course these actions affect the CPU model and/or the number of cores reported by the OS, in which case they will be treated similarly to how hot plugging will be treated. Best regards, Nikos. On Tuesday, July 21, 2026 at 8:24:22 PM UTC+2 Rick Byers wrote: > Hey Alex, > Google Meet has long relied on an extension to get this data, and now, > after extensive testing in the OT, plans to switch to this API to > preserve their existing use cases. Personally I think that, along with > the statements of support from Zoom and others, is sufficient to easily > clear our I2S bar. WDYT? > > Rick > > On Mon, Jul 20, 2026 at 2:57 PM Alex Russell <[email protected]> > wrote: > >> I appreciate the updates, Nikolaos. Thanks, in particular, for updating >> the examples. >> >> I'm concerned that none of the statements of interest linked above (which >> I had missed; appreciate the pointers) actually discuss using the API in >> any way, and Zoom's reply seems to suggest that they either are not aware >> of compute pressure, or need changes in order to provide UI for their users. >> >> Do you have substantive feedback from the Origin Trials from users that >> benefited? Did they suggest any API or behaviour changes? Did you make >> changes as a result? And do you have any view to the hotplug question >> Sangwhan asked? Are you looking to add events to describe changes in a >> future update to the API? >> >> Best, >> >> Alex >> >> On Thursday, July 16, 2026 at 12:58:37 PM UTC-7 Vladimir Levin wrote: >> >>> LGTM3 >>> >>> On Thu, Jul 16, 2026 at 3:38 PM Mike Taylor <[email protected]> >>> wrote: >>> >>>> LGTM2 >>>> On 7/16/26 1:03 p.m., Chris Harrelson wrote: >>>> >>>> Thanks! >>>> >>>> LGTM1 >>>> >>>> On Thu, Jul 16, 2026 at 10:56 AM Nikolaos Papaspyrou < >>>> [email protected]> wrote: >>>> >>>>> My apologies for misspelling the name above. :-( -- >>>>> 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/b9cd6dbc-ab5b-4335-b9fb-f92e7b377d5dn%40chromium.org >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b9cd6dbc-ab5b-4335-b9fb-f92e7b377d5dn%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 [email protected]. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw93hvYAtxM2Do3pZndYuqpjSd%2BYCuFBeAtjFeFXDb1Krg%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw93hvYAtxM2Do3pZndYuqpjSd%2BYCuFBeAtjFeFXDb1Krg%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/563f5831-8546-4a90-9d05-f294cd8d5caf%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/563f5831-8546-4a90-9d05-f294cd8d5caf%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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6bc32b8d-65ee-44ba-af39-7d39615a347fn%40chromium.org.
