ScrollingCoordinator: currently only for the Mac port, parts used by Chromium code is reusable[[BR]] Now supports texture tile scrolling in a separate thread[[BR]] We check for each ScrollView whether or not it can run in the scrolling thread[[BR]] Sending approximate positions back to the main thread[[BR]] Creates a disconnect between what we're showing and what WebCore thinks[[BR]] Trying to create something very similar to the RenderLayer tree into the scroll thread[[BR]] 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[[BR]] We're trying to keep GraphicsLayer semantics low-level, and not include scrolling semantics in them.[[BR]] vangelis: suggesting that scrolling is similar to CSS animations; might be wasteful. Maybe add some semantics to layer tree instead of creating new semantics.[[BR]] weining: scrolling is about more than graphics, it's also about event semantics[[BR]] vangelis: this might be core-animation specific. on chromium we run animations and scrolling in the same thread[[BR]] for touch events, we'd have to pass them in the same way we pass scroll wheel events.[[BR]] We implement the physics of rubber-banding in the thread.[[BR]] data structure might work cross-process[[BR]] 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.[[BR]] smfr: trying to avoid putting css semantics on GraphicsLayer.[[BR]] jamesr: we're manipulating the platform-layers under the hood. Part of the assumptions of the ScrollingCoordinator is the multithread architecture of CA[[BR]] noamr: some of the RenderLayer/GraphicsLayer semantics make this problem harder. This relates to jchaffraix's presentation.[[BR]] vangelis: seems natural to set the relation in the GraphicsLayer tree.[[BR]] noamr: we're mixing graphics and input events, need separation of concerns[[BR]] jamesr: it's a question of whether or not this is done in GraphicsLayer or in PlatformLayer[[BR]] vangelis: should we try to unify some of the tiling implementations?[[BR]] weinig: is there a unifying piece? TextureMapper, CA and Chromium work completely differently.[[BR]] darin: easier to share when there's not a thick platform to build on top, such as CA[[BR]] weining: might run into the same issues, like CA thread-safety guarantees[[BR]] ScrollingCoordinator only works in the main thread, the scrolling thread can be spawned from any other thread.[[BR]] We pass scrolling-position messages back to the render thread from the scrolling thread.[[BR]] The interface we're using for tile-cache is reusable by other ports.[[BR]] jchaffraix: we're trying to split the render-layers, it's orthogonal to the scroll discussion.[[BR]] weining: making an effort to make the scrollableAreas smaller, e.g. by only allocating an Animator when it's actually necessary.[[BR]] jchaffraix: it's about separation of concerns as well as memory saving.[[BR]] next step: more layout info into the scrolling structure, iframe support, background-attachment fix, [[BR]] vangelis: what do we do with fixed-position and stacking context. This breaks some popular sites (techcrunch).[[BR]] weining: we want to put enough information into the scrolling tree.[[BR]] smfr: you could also make a stacking context.[[BR]] weinig: fighting in the CSS WG to make stacking-contexts make more sense.[[BR]] jamesr: thinking about separating to 3 planes[[BR]] weinig: if we can think of ways to optimize RenderLayers, we can do that there[[BR]]