The start of the journey:
Currently, visibility transitions are implemented via a step function where the step happens at time fraction t=1.0. This works well when hiding an animation (consider transitioning opacity to 0.0 and visibility to false). In this case, the visibility gets set to false at the end of the transition and all is well.
However, consider transitioning opacity from 0.0 to 1.0 and visibility to true. In this case, visibility will be false for the duration of the transition and snap to true at the end.
Solutions that involve fixing transitions are a little gross.
* we could permit asymmetric timing functions depending on the target value
* we could force visibility to true at the beginning of the transition (i.e., explicitly tell it not to transition)
It seems simplest to combine the notion of visibility and opacity and not deal with boolean curves at all. Moreover, we can also combine the notion of enabled, but there are gotchas. The goal of the enabled property was to allow toggling of visibility while an element was "in the scene". For example, the fullscreen toast that comes and goes in 2D browsing mode every time you enter fullscreen mode.
Setting these elements to be disabled ensures that they will never appear when toggling visibility if the mode is wrong (eg, we'd never want to show a 2D browsing element in WebVR mode).
This same effect can be accomplished, however, by hiding subtrees. I.e., if we set the opacity of an element at the root of a subtree to zero, then this subtree will be entirely hidden.
If we construct our UiElement hierarchy correctly, then, we can can get the safety afforded to us by the enabled property.
Comment 1 by bugdroid1@chromium.org
, Aug 30 2017