We need to make sure that animations that affect multiple Mus windows but are logically part of the single UI effect are never "partially" started. I.e. we should never have a frame where some windows participating in an animation have started animating, while the others haven't.

This can achieved by bulk-scheduling all animations, e.g. each time after processing a message in the message loop, or before doing SubmitCompositorFrame. 

The same argument applies to all window tree updates, not just animation scheduling, so ideally the mechanism we come up with here should be usable for all window tree updates.

Design proposal:
https://docs.google.com/document/d/1ctJrAKgk1f1hPft44Ue9lnLAlitEIR1AH6oT3097HYI/edit#heading=h.2h8skayk31mb
 

We need to make sure that animations that affect multiple Mus windows but are logically part of the single UI effect are never "partially" started. I.e. we should never have a frame where some windows participating in an animation have started animating, while the others haven't.

This can achieved by queuing up all animation requests in the client lib and then bulk-scheduling them, e.g. each time after processing a message in the message loop, or before doing SubmitCompositorFrame. 

The same argument applies to all window tree updates, not just animation scheduling, so ideally the mechanism we come up with here should be usable for all window tree updates.

Design proposal:
https://docs.google.com/document/d/1ctJrAKgk1f1hPft44Ue9lnLAlitEIR1AH6oT3097HYI/edit#heading=h.2h8skayk31mb