Fix main thread compositable animation UMA
I had this CL that implements animation specific UMA: https://chromium-review.googlesource.com/c/chromium/src/+/636305 In particular, we record frame rate when there is main thread / compositor / main thread compositable animations in this frame. However, the main thread compositable animations is not calculated correctly in the above CL. The result of that is a crash which is tracked in crbug.com/781305. In order to solve the crash, we temporary disabled the main thread compositable animation UMA in here: https://chromium-review.googlesource.com/c/chromium/src/+/753405 Now it is time to re-enable that UMA. This is how we check whether an animation is main thread compositable or not: we first check whether the effects can start on compositor or not. For example, a transform animation will be able to start on compositor. Then we check whether the target element can start on compositor or not. If the target element is not paint into its own backing, we know that this is due to a running experiment. The problem with the above logic is SVG element. For example, if we have a transform animation on an SVG element, the effect can be started on compositor but the SVG element cannot start on compositor. In order to tell whether this is a main thread compositable, we have to exclude the SVG element. This CL fixed the problem. It re-enables a unit test and added another test for SVG element. Bug: 781305 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I030f2e7d2061589ccb0a62f12744b1097855f2f7 Reviewed-on: https://chromium-review.googlesource.com/895409Reviewed-by:Chris Harrelson <chrishtr@chromium.org> Reviewed-by:
Stephen McGruer <smcgruer@chromium.org> Commit-Queue: Xida Chen <xidachen@chromium.org> Cr-Commit-Position: refs/heads/master@{#534820}
Showing
Please register or sign in to comment