[chromium] Initialize compositor's visibility state upon initialization
authorcommit-queue@webkit.org <commit-queue@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 22 Jun 2012 02:39:22 +0000 (02:39 +0000)
committercommit-queue@webkit.org <commit-queue@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 22 Jun 2012 02:39:22 +0000 (02:39 +0000)
commit5eb23de3a29f94e9fc53c718ace4f149d6a3f714
treed0c00c1bc06616ec31943c3bfab2653f7584c4dc
parent2676f7e63bc830d4908719ea9620e0233b6adf6d
[chromium] Initialize compositor's visibility state upon initialization
https://bugs.webkit.org/show_bug.cgi?id=89712

Patch by James Robinson <jamesr@chromium.org> on 2012-06-21
Reviewed by Adrienne Walker.

A given WebViewImpl's visibility state might change any number of times before compositing is enabled. If the
visibility state is not the default (visible) when the compositor is initialized, we need to let it know the
correct visibility state or it will start ticking uselessly in threaded mode.

Tested manually, there's no way to create a new WebViewImpl in a non-visible state in a WebKit test that I know
of.

* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::setIsAcceleratedCompositingActive):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@120995 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit/chromium/ChangeLog
Source/WebKit/chromium/src/WebViewImpl.cpp