Simplify logic of computing main thread compositable animations
A main thread compositable animation means that this animation should be composited such as an opacity or 2d transform, but it is not due to certain check such as RuntimeEnabledFeatures::TurnOff2DAndOpacityCompositorAnimationsEnabled which is designed to be used for an experiment described in crbug.com/754471. Currently our logic is: 1. Check if the effect (such as opacity) can start on compositor or not 2. If 1 is true, and the target element is not paint into its own backing + the target element is not a SVG, then it is a main thread compositable animation. This logic is over complicated. We should really just check whether the run time flag is enabled or not. So this CL simplifies it. We already have unit test in CompositorAnimationsTest to ensure that this change is fine. Bug: 781305 Change-Id: I8f9a1d82fa60eea79018c6cf777a1b45bd565022 Reviewed-on: https://chromium-review.googlesource.com/919316 Commit-Queue: Xida Chen <xidachen@chromium.org> Reviewed-by:Stephen McGruer <smcgruer@chromium.org> Cr-Commit-Position: refs/heads/master@{#537351}
Showing
Please register or sign in to comment