Bug 74813 - Interacting with GMail message lists is sluggish.
Summary: Interacting with GMail message lists is sluggish.
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tables (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Andreas Kling
Depends on:
Reported: 2011-12-18 10:41 PST by Andreas Kling
Modified: 2011-12-18 12:08 PST (History)
1 user (show)

See Also:

Patch (30.13 KB, patch)
2011-12-18 11:15 PST, Andreas Kling
no flags Details | Formatted Diff | Diff
Patch v2 (31.18 KB, patch)
2011-12-18 11:40 PST, Andreas Kling
mitz: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Kling 2011-12-18 10:41:54 PST
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.
Comment 1 Andreas Kling 2011-12-18 11:15:41 PST
Created attachment 119769 [details]
Comment 2 Andreas Kling 2011-12-18 11:40:56 PST
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 3 mitz 2011-12-18 11:45:48 PST
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 };
Comment 4 Andreas Kling 2011-12-18 12:08:00 PST
Committed r103183: <http://trac.webkit.org/changeset/103183>