Currently we update composited proxy count on an element on the main, an on the worker once the message is received.
jbroman@ has pointed out the following side effect of this due to in-flight proxies.
Suppose the following code:
compositorworker.postMessage([new CompositorProxy($el)]);
This can lead to the following sequence of events:
> - main thread creates CompositorProxy
> - incrementCompositorProxiedPropertiesForElement, element needs style recalc
> - main thread posts message to compositor proxy
> - document lifecycle runs, beginning with style recalc (possibly inducing
> layout, compositing update, paint, etc.)
> - main thread proxy loses last reference and is collected
> - decrementCompositorProxiedPropertiesForElement, element needs style recalc
> - document lifecycle runs, beginning with style recalc (possibly inducing
> layout, compositing update, paint, etc.)
> - CompositorWorker deserializes message and builds a CompositorProxy object
> - incrementCompositorProxiedPropertiesForElement, element needs style recalc
> - document lifecycle runs, beginning with style recalc (possibly inducing
> layout, compositing update, paint, etc.)
This is not incorrect, just that we may be promote/de-promite an element unnecessarily.
Comment 1 by majidvp@chromium.org
, Jun 10 2016Status: Assigned (was: Untriaged)