Bug 99382 – Fold setCellLogicalWidths logic into RenderTableSection layout

• Status: RESOLVED
• Resolution: FIXED
• Component: Tables

[Julien Chaffraix]

RenderTable's and RenderTableSection's setCellLogicalWidths propagate the table layout's logical widths to the cells. This is done as a pre-step to doing RenderTableSection::layout as it may dirty the sections.

Our implementation is artificial and adds an extra unneeded cells' walking: if any column's logical width change, we have to relayout all our sections anyway. As we lay our sections / rows, we can mark the cells as we go.

Following the previous paradigm as several advantages:
* avoids calling setNeedsLayout(true, MarkContainingBlockChain) which is a programming error.
* removes the clunky cell's repainting code.
* avoids a cells' walking.
* removes the artificial split between this "phase" and the regular layout.

[Julien Chaffraix]

Created attachment 168809 [details]
Proposed change v1.

[Eric Seidel (no email)]

Comment on attachment 168809 [details]
Proposed change v1.

The logic looks fine.  I wonder what (if any) perf benefit this has.

[Julien Chaffraix]

(In reply to comment #2)
> (From update of attachment 168809 [details])
> The logic looks fine.  I wonder what (if any) perf benefit this has.

Following our discussion, I tried http://www.robohornet.org/#e=resizecol:

Before:

500x10	510.43ms ± 0.69%
500x50	884.67s ± 1.48%

After:

500x10	509.21ms ± 0.75%
500x50	878.89ms ± 1.40%

It's really a wash, which confirmed some of my rough testing on http://dglazkov.github.com/performance-tests/redraw.html.

[Eric Seidel (no email)]

Thanks.

[WebKit Review Bot]

Comment on attachment 168809 [details]
Proposed change v1.

Clearing flags on attachment: 168809

Committed r131465: <http://trac.webkit.org/changeset/131465>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.