Bug 132793 – [WKWebView _updateScrollViewBackground] churns UI-and-CGColors while repainting

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Tim Horton]

Every layer tree commit, we churn various different color objects in _updateScrollViewBackground. There's no reason for this, and it's a complete waste of ~2.5% of the UI process time while repainting quickly.

[Radar WebKit Bug Importer]

<rdar://problem/16877870>

[Tim Horton]

Created attachment 231245 [details]
patch

[WebKit Commit Bot]

Attachment 231245 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:455:  The parameter name "_currentScrollViewBackgroundColor" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.

Comment on attachment 231245 [details]
patch

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

> Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:129
> +    WebCore::Color _currentScrollViewBackgroundColor;

What does the word “current” add here?

> Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:452
> +        color = WebCore::Color(color.red(), color.green(), color.blue(), opacity * 255);

opacity * 255 is not rounding correctly. If you use colorWithOverrideAlpha() from Color.h you’ll get the correct rounding behavior. Something like:
    color.setRGB(colorWithOverrideAlpha(color.rgb(), opacity);

> Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:455
> +    if (_currentScrollViewBackgroundColor.isValid() && _currentScrollViewBackgroundColor == color)

Color’s operator== compares validity, so I don’t understand what the isValid() check here is doing.

[Tim Horton]

Created attachment 231247 [details]
patch

[Tim Horton]

http://trac.webkit.org/changeset/168594

[Darin Adler]

Should we add a UIColor cache too, not just a CGColor cache?

[Tim Horton]

(In reply to comment #7)
> Should we add a UIColor cache too, not just a CGColor cache?

Maybe! Though, with this resolved, I don't see UIColor creation being slow anywhere in traces.