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.
<rdar://problem/16877870>
Created attachment 231245 [details] patch
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.
Created attachment 231247 [details] patch
http://trac.webkit.org/changeset/168594
Should we add a UIColor cache too, not just a CGColor cache?
(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.