WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
72343
[Chromium] Page/layer flashes after GPU-accelerated CSS transition
https://bugs.webkit.org/show_bug.cgi?id=72343
Summary
[Chromium] Page/layer flashes after GPU-accelerated CSS transition
John Bates
Reported
2011-11-14 18:11:01 PST
Page/layer flashes after GPU-accelerated CSS transition
Attachments
Patch
(3.59 KB, patch)
2011-11-14 18:15 PST
,
John Bates
no flags
Details
Formatted Diff
Diff
Patch
(5.58 KB, patch)
2011-11-15 11:38 PST
,
John Bates
no flags
Details
Formatted Diff
Diff
Patch
(5.72 KB, patch)
2011-11-16 10:34 PST
,
John Bates
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
John Bates
Comment 1
2011-11-14 18:15:51 PST
Created
attachment 115080
[details]
Patch
James Robinson
Comment 2
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?
John Bates
Comment 3
2011-11-15 11:38:46 PST
Created
attachment 115210
[details]
Patch
John Bates
Comment 4
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.
James Robinson
Comment 5
2011-11-15 14:06:38 PST
Comment on
attachment 115210
[details]
Patch R=me, cool test
WebKit Review Bot
Comment 6
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
>
WebKit Review Bot
Comment 7
2011-11-15 15:08:07 PST
All reviewed patches have been landed. Closing bug.
Peter Kasting
Comment 8
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.
John Bates
Comment 9
2011-11-16 10:34:29 PST
Created
attachment 115405
[details]
Patch
John Bates
Comment 10
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.
WebKit Review Bot
Comment 11
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
>
WebKit Review Bot
Comment 12
2011-11-16 13:55:13 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug