ScrollingCoordinator: currently only for the Mac port, parts used by Chromium code is reusable
Now supports texture tile scrolling in a separate thread
We check for each ScrollView whether or not it can run in the scrolling thread
Sending approximate positions back to the main thread
Creates a disconnect between what we're showing and what WebCore thinks
Trying to create something very similar to the RenderLayer tree into the scroll thread
The scrolling tree is the data structure that is used by the scrolling thread. We want to add more semantics to the structure to support more cases
We're trying to keep GraphicsLayer semantics low-level, and not include scrolling semantics in them.
vangelis: suggesting that scrolling is similar to CSS animations; might be wasteful. Maybe add some semantics to layer tree instead of creating new semantics.
weining: scrolling is about more than graphics, it's also about event semantics
vangelis: this might be core-animation specific. on chromium we run animations and scrolling in the same thread

for touch events, we'd have to pass them in the same way we pass scroll wheel events.
We implement the physics of rubber-banding in the thread.
data structure might work cross-process
jamesr: using the same sync mechanism as graphics-layers. Qt has the same problem. Glitches if trying to sync graphics-layers and scroll-tree separately.
smfr: trying to avoid putting css semantics on GraphicsLayer.
jamesr: we're manipulating the platform-layers under the hood. Part of the assumptions of the ScrollingCoordinator is the multithread architecture of CA
noamr: some of the RenderLayer/GraphicsLayer semantics make this problem harder. This relates to jchaffraix's presentation.
vangelis: seems natural to set the relation in the GraphicsLayer tree.
noamr: we're mixing graphics and input events, need separation of concerns
jamesr: it's a question of whether or not this is done in GraphicsLayer or in PlatformLayer

vangelis: should we try to unify some of the tiling implementations?
weinig: is there a unifying piece? TextureMapper, CA and Chromium work completely differently.
darin: easier to share when there's not a thick platform to build on top, such as CA
weining: might run into the same issues, like CA thread-safety guarantees

ScrollingCoordinator only works in the main thread, the scrolling thread can be spawned from any other thread.
We pass scrolling-position messages back to the render thread from the scrolling thread.
The interface we're using for tile-cache is reusable by other ports.
jchaffraix: we're trying to split the render-layers, it's orthogonal to the scroll discussion.
weining: making an effort to make the scrollableAreas smaller, e.g. by only allocating an Animator when it's actually necessary.
jchaffraix: it's about separation of concerns as well as memory saving.

next step: more layout info into the scrolling structure, iframe support, background-attachment fix,

vangelis: what do we do with fixed-position and stacking context. This breaks some popular sites (techcrunch).
weining: we want to put enough information into the scrolling tree.
smfr: you could also make a stacking context.
weinig: fighting in the CSS WG to make stacking-contexts make more sense.
jamesr: thinking about separating to 3 planes
weinig: if we can think of ways to optimize RenderLayers, we can do that there