Bug 72343

Summary: [Chromium] Page/layer flashes after GPU-accelerated CSS transition
Product: WebKit Reporter: John Bates <jbates>
Component: New BugsAssignee: John Bates <jbates>
Status: RESOLVED FIXED    
Severity: Normal CC: cc-bugs, darin, jamesr, pkasting, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 72448    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Description John Bates 2011-11-14 18:11:01 PST
Page/layer flashes after GPU-accelerated CSS transition
Comment 1 John Bates 2011-11-14 18:15:51 PST
Created attachment 115080 [details]
Patch
Comment 2 James Robinson 2011-11-14 18:23:15 PST
Comment on attachment 115080 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=115080&action=review

This needs testing directions at least, even if they are manual. Some other comments inline

> Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp:285
> +    if (m_context)

you don't need this check any more, since the only caller is drawLayersInternal() which can't be reached if context is null

> Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp:286
> +        m_context->reshape(std::max(1, viewportWidth()), std::max(1, viewportHeight()));

the style was wrong here before, but this is a good time to fix it - we don't do calls like this with "std::max()" in WebKit, we put a using namespace std; declaration at the top of the .cpp and then just call 'max()'. This file already has the using declaration so just remove the std:: from these callers

looking more closely if we do it this way then we shouldn't need the max() at all - the only callsite is guarded by an if (viewportSize().isEmpty()) check, so we should never get here if width or height <= 0

> Source/WebCore/platform/graphics/chromium/LayerRendererChromium.h:194
> +    void doViewportChanged();

what an ugly function name - i hate all the doXXX() functions.  Do you even need a function here?  there's only one caller, why not just do it there?
Comment 3 John Bates 2011-11-15 11:38:46 PST
Created attachment 115210 [details]
Patch
Comment 4 John Bates 2011-11-15 11:40:58 PST
Comment on attachment 115080 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=115080&action=review

Added a unit test to verify that reshape doesn't happen until drawLayers.

>> Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp:285
>> +    if (m_context)
> 
> you don't need this check any more, since the only caller is drawLayersInternal() which can't be reached if context is null

Done.

>> Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp:286
>> +        m_context->reshape(std::max(1, viewportWidth()), std::max(1, viewportHeight()));
> 
> the style was wrong here before, but this is a good time to fix it - we don't do calls like this with "std::max()" in WebKit, we put a using namespace std; declaration at the top of the .cpp and then just call 'max()'. This file already has the using declaration so just remove the std:: from these callers
> 
> looking more closely if we do it this way then we shouldn't need the max() at all - the only callsite is guarded by an if (viewportSize().isEmpty()) check, so we should never get here if width or height <= 0

Done.

>> Source/WebCore/platform/graphics/chromium/LayerRendererChromium.h:194
>> +    void doViewportChanged();
> 
> what an ugly function name - i hate all the doXXX() functions.  Do you even need a function here?  there's only one caller, why not just do it there?

Done.
Comment 5 James Robinson 2011-11-15 14:06:38 PST
Comment on attachment 115210 [details]
Patch

R=me, cool test
Comment 6 WebKit Review Bot 2011-11-15 15:08:03 PST
Comment on attachment 115210 [details]
Patch

Clearing flags on attachment: 115210

Committed r100340: <http://trac.webkit.org/changeset/100340>
Comment 7 WebKit Review Bot 2011-11-15 15:08:07 PST
All reviewed patches have been landed.  Closing bug.
Comment 8 Peter Kasting 2011-11-15 18:04:16 PST
The new test here is suffering an assertion failure on the Win dbg (1) canary, see e.g.: http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Win%20%28dbg%29%281%29/builds/8094/steps/webkit_unit_tests/logs/stdio

Per jbates I'll roll this out.
Comment 9 John Bates 2011-11-16 10:34:29 PST
Created attachment 115405 [details]
Patch
Comment 10 John Bates 2011-11-16 10:36:29 PST
Comment on attachment 115405 [details]
Patch

CCLayerImpl::draw is a NOTREACHED, so this test needed a fake CCLayerImpl that is drawable. The debug build no longer asserts with this change. PTAL.
Comment 11 WebKit Review Bot 2011-11-16 13:55:09 PST
Comment on attachment 115405 [details]
Patch

Clearing flags on attachment: 115405

Committed r100500: <http://trac.webkit.org/changeset/100500>
Comment 12 WebKit Review Bot 2011-11-16 13:55:13 PST
All reviewed patches have been landed.  Closing bug.