Status Update
Comments
ch...@appspot.gserviceaccount.com <ch...@appspot.gserviceaccount.com> #2
Tram, can you confirm that the behavior is correct if the modifier is moved to the composable inside the AnimatedPane?
ch...@appspot.gserviceaccount.com <ch...@appspot.gserviceaccount.com> #3
Hi Max, yes when the modifiers are moved to the composable inside the AnimatedPane, the PB animations are better than when the modifiers are in the AnimatedPane itself
ch...@appspot.gserviceaccount.com <ch...@appspot.gserviceaccount.com> #5
After some investigation, I can conclude this behavior is consistent with other animation "wrapper" composables, e.g. AnimatedVisibility
. Modifiers should indeed be applied to the children in order to properly participate in the animation.
ch...@appspot.gserviceaccount.com <ch...@appspot.gserviceaccount.com> #7
<b>📍 Found a significant difference at 1 commit.</b>
18 revisions compared.
https://pinpoint-dot-chromeperf.appspot.com/job/16761682610000
<b>Reland "[heap,cppgc] Unified heap incremental marking schedule"</b> by mlippautz@chromium.org
https://chromium.googlesource.com/v8/v8/+/68b1dbfedeba474e008703c613c3c2169d71cca4
v8:gc:cycle:main_thread:full:incremental:mark:cpp: 2.91 → 3.786 (+0.8765) (+30.12%)
Understanding performance regressions:
http://g.co/ChromePerformanceRegressions
Benchmark documentation link:
https://bit.ly/system-health-v8-benchmarks
You can view the full results and re-run the Pinpoint job at:
https://pinpoint-dot-chromeperf.appspot.com/job/16761682610000
If you think Pinpoint blamed the wrong commit, please add issue to
`Chromeperf-CulpritDetection-NeedsAttention` (hotlist:5670048) and
unassign yourself so that a sheriff can help diagnose.
18 revisions compared.
<b>Reland "[heap,cppgc] Unified heap incremental marking schedule"</b> by mlippautz@chromium.org
v8:gc:cycle:main_thread:full:incremental:mark:cpp: 2.91 → 3.786 (+0.8765) (+30.12%)
Understanding performance regressions:
Benchmark documentation link:
You can view the full results and re-run the Pinpoint job at:
If you think Pinpoint blamed the wrong commit, please add issue to
`Chromeperf-CulpritDetection-NeedsAttention` (hotlist:5670048) and
unassign yourself so that a sheriff can help diagnose.
Description
Internal (Googlers-only) Reports:
- Chromium:
(Legacy) Chromeperf Report:
Top 1 regressions (out of 1, with 0 improvements) in this group:
- ChromiumPerf/android-pixel6-pro-perf/v8.browsing_mobile/v8:gc:cycle:main_thread:full:incremental:mark:cpp_avg/browse_media/browse_media_imgur_2019
26.56%: 3.023 -> 3.826 ms
Top 1 affected measurements in android-pixel6-pro-perf:
- v8.browsing_mobile/v8:gc:cycle:main_thread:full:incremental:mark:cpp_avg/browse_media/browse_media_imgur_2019
26.56%: 3.023 -> 3.826 ms
Regressions grouped by v8.browsing_mobile includes data from the following benchmarks with listed owners:
v8.browsing_mobile: cbruni@chromium.org, leszeks@chromium.org
Commits in this range:
Chromium Git Hash:
Chromium Commit Position:
V8 Commit Position:
WebRTC Git Hash: