I explored quick hack just to see what code had to be touched, notes:

- add CSSPropertyVisibility to CompositorAnimations::kCompositableProperties
- add case to existing Opacity case in CompositorAnimations::IsCandidateForAnimationOnCompositor

We then end up failing in CompositorAnimations::GetAnimationOnCompositor where we also need to add a case to handle visibility.

There's existing logic for opacity that we could probably emulate but this is where I decided to pause for checkpoint with Animations team.

Unassigning self as no plan to work on it currently. See also thread "Accelerating Visibility Animation" discussed with animations team.

(A email thread[1] mentions UMA stats and links to this bug)

Keep in mind that the reason we see increased animations on visibility _might_ be because of AMP. Their markup[2] animates visibility as a fallback to reveal the page after 4 seconds if JavaScript takes to long/doesn’t run at all (it’s their FOUC protection mechanism). In their case turning it into an opacity-style animation might be undesired.

[1]: https://groups.google.com/a/google.com/forum/#!topic/threaded-rendering/ybNzkjypOY0
[2]: https://www.ampproject.org/docs/tutorials/create/basic_markup

Assigning to majid to triage feasibility of compositing visibility animations.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot