On 2/13/14 6:45 PM, Patrick Walton wrote:
1. This creates multiple sequential barriers, which can result in a
parallelism hazard. As an extreme case, consider:
<style>div { position: absolute; }</style>
<div><div><div><div><div>...
This will effectively result in fully sequential layout because you have
to wait until layout to finish to start working on the new absolutely
positioned kids you found, and so on.
Well, so...
In this testcase you can't really start laying out the child div until
you're done figuring out the size of the parent div (which then
determines the size of the containing block for the child), right? I
think that's a fundamental serialization issue in the spec for abspos
stuff, but willing to be proved wrong. The good news is that such deep
apspos nesting is a pretty rare case...
There are, I guess, special cases where you can know the size of the
parent before you've finished laying out its kids. By the same token,
there are cases, like tables, where you don't know it even after you've
finished the kids, because there's some nonlocal thing like row height
assignment waiting to happen.
You can try to deal with the latter by redoing the abspos layout if/when
the size changes; it just might be more complicated to do that.
2. The overhead of updating parents' overflow areas over and over again.
In fact a page like above will result in O(n^2) updates of parents'
overflow areas where n is the number of nodes, unless I'm missing
something.
I believe you're right.
Can we tweak the algorithm in some way to avoid these hazards?
I will think on it.
The fragmentation issue worries me more. :(
-Boris
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
