https://issues.chromium.org/issues/337094888 On Friday, February 14, 2025 at 4:26:47 PM UTC+8 uazo wrote:
> > We tested an intervention on Canary/Dev/Beta that reduces the frame > rate by half (e.g., from 60fps to 30fps) after 4 consecutive frames without > pixel changes. > > would it be possible to study the changes you have made in the code? is > there an associated bugid? thank you. > > On Wednesday, February 12, 2025 at 6:41:56 PM UTC-2 Li1 Chen wrote: > >> Hi, >> >> >> >> We have tried Speedometer3 and MotionMark for this feature on pinpoint. >> >> Speedometer3: >> >> https://pinpoint-dot-chromeperf.appspot.com/job/11eca91ea10000 >> >> https://pinpoint-dot-chromeperf.appspot.com/job/166ca91ea10000 >> >> MotionMark: >> >> https://pinpoint-dot-chromeperf.appspot.com/job/11289a3ba10000 >> >> https://pinpoint-dot-chromeperf.appspot.com/job/14289a3ba10000 >> >> >> >> From the pinpoint data we can see that this feature does not affect the >> performance of Speedometer3. It only causes regression in the MotionMark >> subcase Design. The root cause is that the Design case uses rAF to >> calculate the frame length( >> https://github.com/WebKit/MotionMark/blob/baf37c1fcb690abbe048e249e248e7847bddd34f/MotionMark/tests/resources/main.js#L182), >> >> but there is no frame update. Since the frame rate is throttled after 4 >> DidNotProduceFrame, the frame length is reduced to 33ms, which affects the >> complexity calculation in the case and causes regression. In MotionMark >> only Design case uses no-op frame to calculate frame length, which does not >> seem reasonable, so only this subcase is regressed. >> >> >> >> Thanks >> >> Li >> >> >> >> On Monday, February 10, 2025 at 10:22:44 PM UTC+8 Camillo Bruni wrote: >> >>> +1 to double checking the benchmark >>> Most likely we're good as we should have at most a single idle rAF. >>> >>> >>> On Fri, 7 Feb 2025 at 20:13, Johnny Stenback <jste...@chromium.org> >>> wrote: >>> >>>> Hey Francois, >>>> >>>> This sounds promising. My one concern is what effect(s) this might have >>>> on our performance benchmarking work. +Camillo Bruni for his thoughts. >>>> We should at the very least make sure speedometer/motionmark/etc numbers >>>> are not negatively impacted by this change. >>>> >>>> Cheers, >>>> Johnny >>>> >>>> On Fri, Feb 7, 2025 at 10:03 AM Francois Pierre Doray < >>>> fdo...@chromium.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> We tested an intervention on Canary/Dev/Beta that reduces the frame >>>>> rate by half (e.g., from 60fps to 30fps) after 4 consecutive frames >>>>> without >>>>> pixel changes. The frame rate returns to normal immediately upon pixel >>>>> changes or input events. For example: >>>>> >>>>> let last = performance.now(); >>>>> let c = () => { >>>>> window.requestAnimationFrame(c); >>>>> let now = performance.now(); >>>>> console.log(now - last); >>>>> last = now; >>>>> } >>>>> c(); >>>>> >>>>> The c() function's invocation frequency halves after 4 calls due to >>>>> the lack of pixel updates. Note: As a result, a subsequent frame with >>>>> pixel >>>>> updates may be delayed by up to 1 frame (but frame rate returns to normal >>>>> immediately after a frame with pixel updates). >>>>> >>>>> This intervention significantly improves LCP, INP and CPU usage on >>>>> Beta, confirming our prior observation that no-op frames often occupy the >>>>> main thread during page load or input handling. To validate these >>>>> results, >>>>> we need a 1% stable experiment (user behavior differs between pre-stable >>>>> and stable channels). Before proceeding, we'd appreciate feedback on >>>>> potential issues this experiment might cause. We will determine our next >>>>> steps based on input from this discussion. >>>>> >>>>> Thanks, >>>>> >>>>> François >>>>> >>>>> [cc: Chen, Li and Zheng, Hong from Intel who proposed and >>>>> implemented this intervention] >>>>> >>>>> -- >>>>> 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 blink-dev+...@chromium.org. >>>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6db8984-6c56-4e84-954b-7b0ffae8b461n%40chromium.org >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6db8984-6c56-4e84-954b-7b0ffae8b461n%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> Camillo Bruni | Software Engineer, V8 | Google Germany GmbH | >>>> Erika-Mann >>> Str. 33, 80636 München >>> >>> Registergericht und -nummer: Hamburg, HRB 86891 | Sitz der >>> Gesellschaft: Hamburg | Geschäftsführer: Paul Manicle, Halimah DeLaine >>> Prado >>> >>> Diese E-Mail ist vertraulich. Falls Ssie 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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/508886fc-971d-4371-8c9f-a7fb828275d1n%40chromium.org.
