For the first concern, I realized that pages like that are going to be
sequential no matter what we do, of course, because of the way parallel tree
traversals work. So never mind there. The O(n^2) update of overflow areas still
concerns me though.
Patrick Walton <pcwal...@mozilla.com> wrote:
>On 2/13/14 2:42 PM, Boris Zbarsky wrote:
>> Then you go through this list (this part should parallelize pretty
>> nicely, btw, except for the overflow area updates on parents) and
>reflow
>> them all, since now you know their containing block sizes, and you
>> update overflow areas. Again, if there are abs pos kids you add to a
>> list, etc.
>
>I have a couple of concerns about this from a performance point of
>view.
>
>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.
>
>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.
>
>Can we tweak the algorithm in some way to avoid these hazards?
>
>Patrick
>
>_______________________________________________
>dev-servo mailing list
>dev-servo@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-servo
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
