Breakout from http://crbug.com/674317 . We've not yet ported some logic from CompositedLayerMapping::updateElementIdAndCompositorMutableProperties() around setting element id and CompositorMutableProperties in the presence of compositor worker enabled. I expect we'll need to add a field(s) for CompositorMutableProperty to paint property node(s), and add some logic to PaintPropertyTreeBuilder to populate.
Before doing this work I thought to checkpoint and make sure the Compositor Worker feature is still planned to build atop the existing implementation.
Should we do this porting work? Guessing a couple of days to port and write/update tests, potential for work discovery if for example changes we've made to when we call updateAnimations() for SPv2 somehow have deeper lifecycle ramifications for compositor worker.
Involved failing tests are:
virtual/threaded/fast/compositorworker/visual-update.html [ Timeout ]
virtual/threaded/fast/compositorworker/basic-plumbing-main-to-worker.html [ Crash Failure ]
virtual/threaded/fast/compositorworker/basic-plumbing-worker-to-main.html [ Crash Failure ]
virtual/threaded/fast/compositorworker/compositor-attribute-change-worker.html [ Timeout ]
virtual/threaded/fast/compositorworker/compositor-proxy-disconnect-worker.html [ Timeout ]
Comment 1 by flackr@chromium.org
, Jan 30 2017