On Tue, Jul 21, 2026, 1:10 PM Philipp Hancke <[email protected]> wrote:
> Am Di., 21. Juli 2026 um 21:53 Uhr schrieb Sangwhan Moon <[email protected] > >: > >> Specifically, on ChromeOS if you are in power saving mode cores are >> pulled offline or downclocked. >> >> So without an observer mechanism - if you load a an app while battery >> saver is active you'll be stuck in degraded mode until you reload. The only >> workaround would be for the app to poll and see if the core config changed >> > > But "web developers" could reevalute the cpu performance if they detect > compute pressure states hanging? > Compute pressure is roughly (in_use / available), and if you are under battery saver + low load it will say no pressure. I believe in the case I mentioned the transition would likely would be in the lines of: (1) Low capacity + low pressure (2) Low capacity + high pressure <Charger plugged> (3) High capacity + low pressure I believe the current design would put a ceiling on the app to get lower tier at (1), degrade at (2), and if not careful (e.g. poll cpu info again when pressure changes) at point (3) will keep the app at a ceiling set to the bar from (1). > > It would probably help to show a concrete example of how both APIs > complement each other. > https://github.com/webrtc/samples > is a highly starred repository that covers the use-case of both Zoom and > gMeet > > ("there is a sample for that" still works in 2026 hopefully!) > > >> , but this would be an antipattern (there is no "battery saver event" >> exposed to the web, as it allows for correlating users. >> >> That thread can be pulled from here: >> https://source.chromium.org/search?q=HotplugCpuAction&sq=&ss=chromiumos%2Fchromiumos%2Fcodesearch:src%2Fplatform2%2Fresourced%2Fsrc%2F >> > > hrm... does compute pressure listen to that? > > >> One other minor bit that comes to mind is how this would work with DVFS >> <https://developer.arm.com/documentation/100960/0100/Dynamic-Voltage-and-Frequency-Scaling>, >> if frequency is used for bucketing and the read time is pre-ramp. >> >> On Tue, Jul 21, 2026 at 11:35 AM Nikolaos Papaspyrou < >> [email protected]> wrote: >> >>> 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/CA%2B9RimwB7iZA4%2Bv3w8JrJfhJtsPH-%3DyXekf8%2Bg2giwkCuRcNXg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B9RimwB7iZA4%2Bv3w8JrJfhJtsPH-%3DyXekf8%2Bg2giwkCuRcNXg%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/CAOZWpL7X%3DEg8-6Qwu%2BAdN02kEWv1he1ZwfAKc%3DG%3DP%2B-ffC5PgA%40mail.gmail.com.
