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