Bug 74813 – Interacting with GMail message lists is sluggish.

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

[Andreas Kling]

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.

[Andreas Kling]

Created attachment 119769 [details]
Patch

[Andreas Kling]

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 };

[Andreas Kling]

Committed r103183: <http://trac.webkit.org/changeset/103183>