| Summary: | [chromium] Renderer is resizing IOSurfaces when accelerated compositing is disabled. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Jonathan Backer <backer> | ||||||||
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Normal | CC: | backer, commit-queue, kbr, simon.fraser, webkit.review.bot | ||||||||
| Priority: | P2 | ||||||||||
| Version: | 528+ (Nightly build) | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Jonathan Backer
2010-11-19 13:57:38 PST
Created attachment 74423 [details]
Patch
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. Comment on attachment 74423 [details]
Patch
If it looks OK, can you please commit because I don't have committer status.
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? This bug has the worst title ever. What is resizing too often, and why? 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. Comment on attachment 74423 [details]
Patch
Please update the ChangeLog with the new synopsis.
Created attachment 74654 [details]
Patch
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.
Created attachment 74655 [details]
Patch
Comment on attachment 74655 [details]
Patch
Looks good to me.
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 kmccullough@apple.com, oliver@apple.com, pol@apple.com, and timothy@apple.com. The commit-queue is continuing to process your patch. 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 dbates@webkit.org. The commit-queue is continuing to process your patch. Comment on attachment 74655 [details] Patch Clearing flags on attachment: 74655 Committed r72623: <http://trac.webkit.org/changeset/72623> All reviewed patches have been landed. Closing bug. |