Bug 201412 – [FTW] Cache Gradients in the WebContent process

• Status: RESOLVED
• Resolution: INVALID
• Component: WebCore Misc.

[Brent Fulgham]

Profiling shows that creating Gradient brushes are one of the highest remaining hot spots in MotionMark runs, especially in Suits.

This benchmark ends up applying one of a set of gradients to different elements, and creating and destroying these gradient brushes each time we paint is hugely wasteful.

This patch adds a local cache to the Direct2D Gradient object that caches the constructed gradient.

[Brent Fulgham]

Created attachment 377869 [details]
Patch

[Brent Fulgham]

Sadly, this change showed no improvement when A/B testing Motion ark. :(

[Anders Carlsson]

Comment on attachment 377869 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=377869&action=review

Probably worth coming up with a cache eviction strategy - otherwise the hash maps will just grow indefinitely.

> Source/WebCore/platform/graphics/win/GradientDirect2D.cpp:59
> +static HashMap<unsigned, COMPtr<ID2D1LinearGradientBrush>> linearGradients;
> +static HashMap<unsigned, COMPtr<ID2D1RadialGradientBrush>> radialGradients;

These will introduce global constructors.

> Source/WebCore/platform/graphics/win/GradientDirect2D.cpp:85
> +    unsigned hash = this->hash();

It's not enough to just use the hash value here.

If two different gradients happens to hash to the same value, one of them will get the wrong brush.

> Source/WebCore/platform/graphics/win/GradientDirect2D.cpp:98
> +            m_gradient->AddRef();

Seems like it would be better if PlatformGradient was a COMPtr; that would get rid of the manual memory management here.