including porkjockeys
karnaze wrote:
> Table reflow can be made faster in at least 3 ways. The 1st is mostly
> implemented. Although the 2nd seems doable, after some preliminary
> testing on the block code, it may bring out additional bugs in the block
> code.
>
> 1) Minimize the number of reflows which require rebalancing the columns
> (and then usually reflowing every cell to fit). The pres shell will
> notify frames which are ancestors of an incremental reflow command
> target that a reflow command will be coming. Tables can keep track of
> the number of pending reflows of descendants and not rebalance (and
> reflow every cell) when there are still reflows coming. This is tables'
> answer to reflow coalescing.
>
> Acutally, it is a little more complicated than this to account for the
> pres shell's ability to interrupt the reflow process. So the pres shell
> will have an additional reflow command queue which frames can append
> reflow commands to (indirectly) and this queue is guaranteed to be
> processed before the pres shell gives up control. Tables request such
> reflow commands when they decide to delay their rebalancing as above.
> They can also cancel the commands if they are no longer needed.
>
> 2) When new row or cell frames get appended, reflow the new cells
> initially at the current width of the appropriate table column(s) rather
> than 1st with an unconstrained width and then 2nd with a real one. If
> the table doesn't need to be rebalanced or if optimizaion #1 holds, then
> the number of reflows on cells has been reduced. This makes the
> assumption that during an initial reflow a block can set
> max-element-size and maximum width even if it isn't being reflowed with
> an unconstrained width. The assumption appears to be correct.
>
> 3) Remove all of the cases where each cell in the table is reflowed
> again (after its initial reflows) to get max-element-size and maximum
> width. Once this information is obtained it isn't necessary to get it
> again unless an incremental reflow affects a particulay cell.
>
> In addition, some optimizations have recently gone into the tree which
> have improved table reflow performance including: (a) stopped
> rebalancing nested tables just to get their maximum widths, (b) removed
> an excessive number of colspan calculations when a colspan spans a
> percent column, (b) cached the last available width on the row group to
> avoid doing anything in degenerate yet common cases.
