You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Blink raised concerns with quadratic performance of intrinsic track sizing with spanning items, filing this issue to track that item specifically (as opposed to the exponential issue tracked in #9326). See comments in #8206 and #9041
I'm also concerned that considering all non-explicitly placed grid items in every posible start position will likely result in bad performance, that's a guaranteed quadratic algorithm.
The proposal outlined to address the placement/sizing mismatch in #8206 (comment) could result in approximately quadratic performance, even in very simple cases.
The text was updated successfully, but these errors were encountered:
It's completely fine to have any arbitrary mixture of fixed and/or flexible tracks. They can be fully sized without regards to content, so there's no issue.
It's fine to have multiple intrinsic-sized tracks that are the exact same size (aka a repeat(5, auto) or something). These can be dealt with by just measuring every item ahead of time (and adjusting the measured size to handle spanning items; subtract the gaps and divide by the span).
It's fine to have any arbitrary mix of tracks, intrinsic or otherwise, if there are no spanning elements (or if spanning elements don't contribute to the size of columns). Again, you just measure every item once, and then account for the potential of them being in each track; it's slightly more work than the previous bullet, but not unreasonable. (Technically the complexity of this is also (number of items * number of tracks), but taking the measurements of an element into account for each of the tracks is much simpler/cheaper when they're only touching one track at a time).
The potential perf issue arises when you have an intrinsic-sized track mixed with any other-sized track, and there are spanning items. This requires you to lay out the spanning items multiple times, for every possible position crossing one or more intrinsic tracks; this behavior is quadratic (in the number of spanning items times the number of columns, which can both be arbitrarily large).
(as opposed to the exponential issue tracked in #9326).
This is actually identical to the exponential issue. The behavior listed here is quadratic for most grid items; it becomes exponential if the spanning items are subgrids (or rather, sub-masonrys) and contain their own spanning items.
This requires you to lay out the spanning items multiple times, for every possible position crossing one or more intrinsic tracks; this behavior is quadratic (in the number of spanning items times the number of columns, which can both be arbitrarily large).
Afaict, you don't actually have to lay out the items here? You're just taking their minimum / min-content / max-content sizes. Why would you need to lay them out for intrinsic track sizing?
Blink raised concerns with quadratic performance of intrinsic track sizing with spanning items, filing this issue to track that item specifically (as opposed to the exponential issue tracked in #9326). See comments in #8206 and #9041
The text was updated successfully, but these errors were encountered: