Animation Worklet - measure performance impact |
|||||||||
Issue descriptionWe should be able to measure the performance of AnimationWorklet. To start we want to measure the following: a- total time from mutate signal to getting update b- pat of that time spent in v8 executing. T (a) will eventually become part of the scheduler to anticipate how much time we need and schedule mutation and activation accordingly.
,
Nov 7 2017
On my pixel on https://flackr.github.io/houdini-samples/animation-worklet/parallax-scrolling/ with the patches for running on a dedicated thread[1] and scroll timelines[2], for a single mutate from AnimationHost::Tick*Animations, I get roughly 0.348ms total: 0.153ms on compositor 0.165ms on worklet ~0.03ms signal delay? But the actual v8.callFunction on the worklet only takes 0.042ms. This means we're spending quite a bit of time in our C++ code. We should try to reduce this. [1] https://chromium-review.googlesource.com/c/chromium/src/+/630857 [2] https://chromium-review.googlesource.com/c/chromium/src/+/738437
,
Feb 5 2018
,
Feb 22 2018
,
Mar 5 2018
,
Apr 3 2018
,
Oct 22
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7a037e99bc9adc1aafcb96c40c9097ba3210909b commit 7a037e99bc9adc1aafcb96c40c9097ba3210909b Author: Majid Valipour <majidvp@chromium.org> Date: Mon Oct 22 23:37:15 2018 [animation-worklet] Add basic UMA metrics Add two different metrics: - Duration of mutate in dispatcher. This represents the main per-frame cost that is experienced by animation worklet clients. - Duration of mutate in globalscope. This is the main per-frame cost for each global scope. Bug: 780528 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Icb7a369534bd0bd8e0e2b9e2cddc5e632eaf50df Reviewed-on: https://chromium-review.googlesource.com/c/951922 Commit-Queue: Majid Valipour <majidvp@chromium.org> Reviewed-by: Alexei Svitkine <asvitkine@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Cr-Commit-Position: refs/heads/master@{#601780} [modify] https://crrev.com/7a037e99bc9adc1aafcb96c40c9097ba3210909b/base/metrics/histogram_macros.h [modify] https://crrev.com/7a037e99bc9adc1aafcb96c40c9097ba3210909b/third_party/blink/renderer/modules/animationworklet/animation_worklet_global_scope.cc [modify] https://crrev.com/7a037e99bc9adc1aafcb96c40c9097ba3210909b/third_party/blink/renderer/platform/graphics/animation_worklet_mutator_dispatcher_impl.cc [modify] https://crrev.com/7a037e99bc9adc1aafcb96c40c9097ba3210909b/tools/metrics/histograms/histograms.xml
,
Jan 8
,
Jan 8
,
Jan 9
kevers@ is adding async scheduling to AW which involves dropping frames if we are working on a frame already. We probably should track this as well in our metrics. Perhaps this can be a component of a more general smoothness metric. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by majidvp@chromium.org
, Nov 3 2017