Tracking composited animation and scrolling with ElementIds instead of layer ids

[Philip Rogers]

TL;DR: Don't add new dependencies on animation layer ids or scrolling layer ids, use element ids.

ElementIds are a stable identifier for the compositor that represent the html node[1] responsible for effects like animations and scrolling. The paint team is moving towards using these stable element ids for tracking animations and scrolling instead of relying on layers. This will let blink make more general layerization decisions such as splitting up a scrollable area into multiple Layers, in addition to moving more logic off Layer.

I'm in the middle of refactoring composited scrolling (https://crbug.com/693740) to be based on element ids (e.g., tracking the currently scrolling element id instead of the currently scrolling layer id). This decouples Layers from scrolling which will be primarily handled in the scroll property tree where scroll geometry is also needed.

This refactoring has the following implications:

* Removes the reference from ScrollNode to Layer (ScrollNode's owning_layer_id) though there will be a reference from Layer to ScrollNode (Layer's scroll_tree_index).

* Keeps the 1:1 relationship between ScrollNode and ElementId (ScrollTree's element_id_to_scroll_node_index and ScrollNode's element_id).

* Removes the the 1:1 mapping from ElementId to Layer, replacing it with a 1:N relationship so LayerTreeImpl::LayerByElementId will need to become LayersByElementId (or similar).

Lots of folks are also working in this space. Weiliang Chen is working on using element ids to tick animations in http://crbug.com/702774. Jayadev Dasika is removing the need to use Layers for property tree nodes. Walter "The Animator" Korman is refactoring composited animations to not use layer ids in http://crbug.com/709137. 

These are pretty big conceptual change so we wanted to share the motivation and details.

[1] For most cases you can think of ElementId as representing a single blink element but it's actually slightly more. ElementId is backed by a primary id (the element) and a secondary id for when there are multiple effects from a single element. See cc's element_id.h and blink's CompositorElementId.h.

[Steve Kobes]

This sounds exciting!

How will scroll offsets be synchronized between Blink and cc after this change?  Today they go through cc::Layer in both directions (SetScrollOffset / SetScrollOffsetFromImplSide).

[Jayadev Dasika]

I think the plan is to move scroll offsets to scroll tree and then directly talk to scroll nodes to update them instead of going through cc::Layer. 

--
You received this message because you are subscribed to the Google Groups "paint-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to paint-dev+...@chromium.org.
To post to this group, send email to pain...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAAjAU%3Dbimoxg1nSnaDB6Uu99UcO2nD3hNEmVm8LBOLJ2en03Cg%40mail.gmail.com.

[Philip Rogers]

+1 to Jayadev's response: the plan is to move scroll logic off layers and into the scroll tree.

This is sort of doing this TODO(enne) in layer_impl.cc:

void LayerImpl::UpdatePropertyTreeScrollOffset() {

  // TODO(enne): in the future, scrolling should update the scroll tree

  // directly instead of going through layers.

...

https://cs.chromium.org/chromium/src/cc/layers/layer_impl.cc?q=layer_impl.cc&l=723

To unsubscribe from this group and stop receiving emails from it, send an email to paint-dev+unsubscribe@chromium.org.

To post to this group, send email to pain...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAAjAU%3Dbimoxg1nSnaDB6Uu99UcO2nD3hNEmVm8LBOLJ2en03Cg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Graphics-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to graphics-dev+unsubscribe@chromium.org.