> 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/1183c96e-7bae-49b5-baf0-eb67f1c8dba2n%40chromium.org.
