Passing to vollick@ for triage

For clear bug ownership, the Blink>Animation component has a policy of one-component-per-bug except in limited circumstances (high-level tracking bugs where there is no concrete work like CLs done against them). So, to clarify, is this a high-level tracking bug? What concrete work is required from the animations team for this effort?

Consulting with others here, I think this is a high-level tracking bug, so labelling it as such. From the description in the bug, it's not clear what this issue involves or is expected to cover. Please link to a design doc when there is one. Thanks!

This corresponds to phase two of Mus+ash project (Salamander) when CC is going to be moved to the Mus GPU process, and thus animations are going to be running in GPU as well. The desire is to have the same animation engine power blink/web animations, as well as the browser UI animations. There is no design doc for this specifically. This is a long term plan, and nobody in Mus+ash team is currently working on this, as we are focused on shipping Mus+ash phase 1 (Tadpole).
Some high-level Salamander design docs:
- https://docs.google.com/document/d/1mo9qYcSC-SirLfYJVMOBMvJEm-J985PjmIg7hNZ9QP0/edit#
- (only slide #13 is directly relevant) https://cdn.rawgit.com/chromium/mus-preso/a5701889/blinkon/index.html#13

It's a tracking bug.

Great, thanks for the extra info.

Does this mean literally the same animation engine code will be running in Blink and the GPU?
Is there anything in MUS' design that's blocked on having this over the current state of a Blink main thread animation engine communicating with a cc animation engine?

Animation engine will only run in GPU. The same engine will power Blink animations and browser UI animations. From Blink's perspective, CC/Main thread boundary turns into a Blink/GPU process boundary.

A different way of putting this: the general idea of mus-salamander is that much of the functionality of the CC impl thread moves from the renderer process into the (salamander) mus gpu process. Note though that this is a long-term goal so there's lots of time to hash out the details.

Using the same animation engine between Blink and cc is a long term desire for us as it removes code duplication and buggy differences in behaviour. We certainly have no objection to the idea.

I'm just not sure why this is a requirement for MUS given that it's conceptually taking what was in cc and putting it in the GPU process. The Blink main thread can still be the current animation engine just talking to a different provider of accelerated animations.

I don't think this is blocking anything right now. I'm removing the displaycompositor and the blocking field.

Deprecating label Proj-Mustash-Mus-WS in favor of Components.

Bug scrub: Is this still relevant for mustash?