When my system is under load, interacting with message lists on GMail (e.g the Inbox) gets pretty sluggish. Instruments tells me we're spending most of the time below RenderStyle::colorIncludingFallback(). It appears that when calculating the overflowClipRect() for RenderTableCells, we compute the color for each border side, and then discard it. We should find a way to avoid this when we're only interested in layout metrics.
Created attachment 119769 [details] Patch
Created attachment 119771 [details] Patch v2 Same patch + avoid computing the color property ID for before/after borders when we don't need it.
Comment on attachment 119771 [details] Patch v2 View in context: https://bugs.webkit.org/attachment.cgi?id=119771&action=review > Source/WebCore/rendering/RenderTableCell.cpp:529 > + int beforeColorProperty = CSSProperty::resolveDirectionAwareProperty(CSSPropertyWebkitBorderBeforeColor, table->style()->direction(), table->style()->writingMode()); > + int afterColorProperty = CSSProperty::resolveDirectionAwareProperty(CSSPropertyWebkitBorderAfterColor, table->style()->direction(), table->style()->writingMode()); Do these still need to be resolved in the !computeColor case? > Source/WebCore/rendering/RenderTableCell.h:38 > +enum EComputeBorderColor { IgnoreBorderColor, ComputeBorderColor }; Please don’t use this obsolete naming convention. A better definition would be enum IncludeBorderColorOrNot { DoNotIncludeBorderColor, IncludeBorderColor };
Committed r103183: <http://trac.webkit.org/changeset/103183>