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