Today layout is usually deferred by using a timer which fires after style change is done. This reduces the number of layouts needed. But if the style change results in accelerated compositing layers to be created, they will get created with 0 size because they haven't been laid out yet. This will sometimes cause a compositing to occur with the 0 size layers. When the timer fires, the contents of the layers is laid out and rendered. Then the compositor renders the result and all is well. It is possible to see a visible flash when this occurs. You can see it on http://mycommute.apple.com. You need a build with ACCELERATED_COMPOSITING turned on. Select a Route of "Van Ness/Mission", a Stop of "Colma Park & Ride" and a Campus of "IL1". Then click done and ht the back and forward arrows button a few times. You may be able to see the flash. This is hard to see on fast hardware, but easy on slower platforms.
Created attachment 29104 [details] Patch
Comment on attachment 29104 [details] Patch r- based on discussion with Darin. We need to just fix the deferred layout timer to fire at the right time.
Created attachment 29231 [details] Replacement patch
Comment on attachment 29231 [details] Replacement patch r=me
Comment on attachment 29231 [details] Replacement patch > + if (!_private->useDocumentViews) > + [self _viewWillDrawInternal]; This needs an #if USE(ACCELERATED_COMPOSITING) around it, or it will throw an exception since that method wont exist.
Never mind, I see the caller has the correct #ifndef around it.
Sending WebCore/ChangeLog Sending WebCore/page/ChromeClient.h Sending WebCore/rendering/RenderLayerCompositor.cpp Sending WebCore/rendering/RenderLayerCompositor.h Sending WebKit/mac/ChangeLog Sending WebKit/mac/WebCoreSupport/WebChromeClient.h Sending WebKit/mac/WebCoreSupport/WebChromeClient.mm Sending WebKit/mac/WebView/WebView.mm Sending WebKit/mac/WebView/WebViewInternal.h Transmitting file data ......... Committed revision 42208.