Changes between Version 1 and Version 2 of Scrolling Session Meeting 2012


Ignore:
Timestamp:
Apr 25, 2012 11:09:34 AM (9 years ago)
Author:
jchaffraix@webkit.org
Comment:

Added line breaks for better formatting, also fixed my name

Legend:

Unmodified
Added
Removed
Modified
  • Scrolling Session Meeting 2012

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