[Webkit-unassigned] [Bug 165007] New: [meta] [css-grid] Isolate track sizing and items placement data from RenderGrid internal state

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Nov 21 03:30:11 PST 2016


https://bugs.webkit.org/show_bug.cgi?id=165007

            Bug ID: 165007
           Summary: [meta] [css-grid] Isolate track sizing and items
                    placement data from RenderGrid internal state
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: svillar at igalia.com
                CC: simon.fraser at apple.com

The most important piece of code in RenderGrid is the track sizing algorithm which is used to determine the sizes of the tracks (rows and columns) of the grid. That algorithm is used for both the layout phase and the preferred widths (intrinsic size) computations. The problem is that both computations are using exactly the same data structures cached in the RenderGrid object. That's nice for performance reasons but it is also a potential source of problems. 

The risk is low ATM because we do always clear those caches after a layout or a preferred widths computation but that is something that will not stay forever like this, as we want to reuse some computations between layouts (like the placement of items) in order to improve performance. Actually it's already causing some issues right now, like for example the need of using ugly const_casts in computeIntrinsicLogicalWidths() which is supposed to be a const method.

I'm filing this metabug as the process will require several patches.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161121/b51b553c/attachment.html>


More information about the webkit-unassigned mailing list