Bug 49827 – [chromium] Renderer is resizing IOSurfaces when accelerated compositing is disabled.

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Jonathan Backer]

Resizing too often.

[Jonathan Backer]

Created attachment 74423 [details]
Patch

[Jonathan Backer]

When accelerated compositing is triggered, m_layerRenderer is created. If we fall back to software rendering, m_layerRenderer is still set. At this point, we are resizing unnecessarily.

[Jonathan Backer]

Comment on attachment 74423 [details]
Patch

If it looks OK, can you please commit because I don't have committer status.

[Alexey Proskuryakov]

Even though this is platform-specific code, it still needs a regression test, or an explanation of why there is none. Is this a measurable performance improvement?

[Simon Fraser (smfr)]

This bug has the worst title ever. What is resizing too often, and why?

[Jonathan Backer]

Updated the title to be more descriptive. Accelerated compositing on the Mac OS X version of Chromium (the only port currently using this code path) is to IOSurfaces, which do not need to be resized when accelerated compositing is disabled. As these surfaces are not visible when accelerated compositing is disabled, it does not cause any display artifacts. Fixing this bug will improve performance, but that improvement will probably be slight.
 
This change is intended as a code clean-up in preparation for using this code path on Linux (http://codereview.chromium.org/5105006/) and Windows (http://codereview.chromium.org/4815001/). On the Linux side, this change does cause a noticeable performance improvement (less lag when switching from software rendering to accelerated compositing after doing a bunch of resizes). An improvement was not noticed on the Windows side.

[Kenneth Russell]

Comment on attachment 74423 [details]
Patch

Please update the ChangeLog with the new synopsis.

[Jonathan Backer]

Created attachment 74654 [details]
Patch

[WebKit Review Bot]

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

Failed to run "['WebKitTools/Scripts/check-webkit-style', '--diff-files', u'WebKit/chromium/ChangeLog', u'WebKit/chromium/src/WebViewImpl.cpp']" exit_code: 1
WebKit/chromium/ChangeLog:8:  Line contains tab character.  [whitespace/tab] [5]
WebKit/chromium/ChangeLog:9:  Line contains tab character.  [whitespace/tab] [5]
Total errors found: 2 in 2 files


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

[Jonathan Backer]

Created attachment 74655 [details]
Patch

[Kenneth Russell]

Comment on attachment 74655 [details]
Patch

Looks good to me.

[WebKit Commit Bot]

The commit-queue encountered the following flaky tests while processing attachment 74655 [details]:

transitions/transition-timing-function.html
fast/profiler/throw-exception-from-eval.html

Please file bugs against the tests.  These tests were authored by [e-mail], [e-mail], [e-mail], and [e-mail].  The commit-queue is continuing to process your patch.

[WebKit Commit Bot]

The commit-queue encountered the following flaky tests while processing attachment 74655 [details]:

http/tests/security/xssAuditor/full-block-link-onclick.html

Please file bugs against the tests.  These tests were authored by [e-mail].  The commit-queue is continuing to process your patch.

[WebKit Commit Bot]

Comment on attachment 74655 [details]
Patch

Clearing flags on attachment: 74655

Committed r72623: <http://trac.webkit.org/changeset/72623>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.