Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8af27c463fdd50a252381bdaf154c7008a6a7257
https://github.com/WebKit/WebKit/commit/8af27c463fdd50a252381bdaf154c7008a6a7257
Author: Sammy Gill <[email protected]>
Date: 2025-06-04 (Wed, 04 Jun 2025)
Changed paths:
A PerformanceTests/Layout/grid-with-nested-grid-and-subgrid-columns.html
M Source/WebCore/rendering/RenderGrid.cpp
Log Message:
-----------
REGRESSION(281090@main): Grid layout can be slow on pages with deeply nested
grid and subgrid content.
https://bugs.webkit.org/show_bug.cgi?id=291827
rdar://149704403
Reviewed by Alan Baradlay.
In 287890@main, we introduced a new cache for grid layout to use by
storing the intrinsic logical height of its grid items. That commit
message gives the explanation for the cause of the performance
regression, but the TLDR is:
We can experience some thrashing when we have deeply nested grid content
that is also stretching. This is because the track sizing algorithm will
query its item for its intrinsic logical height, and on relayout, we will
setNeedsLayout on those items to get that information. This behavior can
become pathological if those items are grid themselves.
The cache in 287890@main stores those sizes for grid to use without
needing to perform layout on those items. However, we restricted the
availability of this cache to limit the scope and risk of the initial
implementation. One of these restrictions was to not create that cache
in the presence of subgrids. As a result, any pages with subgrids and a
similar content structure of nested grids/subgrids can experience the
same performance problem that 287890@main attempted to address.
It seems like at one point, lobste.rs experienced this issue when the
website changed. This content structure no longer appears on the site at
this point, although that state is still accessible via the
Wayback Machine (see the link in the bugzilla).
The content seems to have been of the form:
<grid>
<subgrid column/>
<subgrid columns/>
<grid>
...
</grid>
</grid>
which was used in the comments section.
In this patch, we expand the availability of this cache to include when
the RenderGrid is subgridded in the columns or has a grid item which is
a subgrid columns. This should be okay for the following reason:
1.) A grid with subgridded columns and *not* rows will create its own
rows that are independent from the root grid. As a result, it will
perform track sizing on those rows and will need the cache for the exact
same reason.
2.) The shared columns should not impose a restriction on the cache
since the only time it should be used is for the first pass of row
sizing.
However, we impose an additional restriction to limit the cache if there
are any orthogonal subgrids. This is mostly just as a simplification to
not have to worry about dealing with the writing mode flips.
This mostly resolves the issue on lobste.rs as we can now load the page,
but there are still some visual glitches when resizing the viewport quickly.
This is because there are some row subgrids on the page, although not as
many, in which we still experience some slowness. I plan to address this
in a follow-up patch as this will require some additional logic to
handle it.
The performance test that was added went from ~3 runs/s -> 55k runs/s
on my M1 Ultra Studio.
Canonical link: https://commits.webkit.org/295826@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
