diff options
author | Nicolas Roard <nicolasroard@google.com> | 2011-10-18 13:07:37 -0700 |
---|---|---|
committer | Nicolas Roard <nicolasroard@google.com> | 2011-10-18 13:11:38 -0700 |
commit | 8cc0fa17a42ae1dec75fe8ab00d5baa75e46499e (patch) | |
tree | 47706253c7de7e041b9c31b1f7c93f5e706a0ad6 /Source/WebCore/platform/wx/SharedBufferWx.cpp | |
parent | a6d06cef38891b6e39dcbc455f7692f000309ba5 (diff) | |
download | external_webkit-8cc0fa17a42ae1dec75fe8ab00d5baa75e46499e.zip external_webkit-8cc0fa17a42ae1dec75fe8ab00d5baa75e46499e.tar.gz external_webkit-8cc0fa17a42ae1dec75fe8ab00d5baa75e46499e.tar.bz2 |
Re-enable animations on the UI thread
Using webkit to compute animations is still slow in some cases.
When animating large elements, we seems to sometimes bogs the GPU,
which then makes the UI takes longer to render a frame. This in turn
slow the rate at which we can call into webkit (to update the position
of the animated layers), which results in perceived stuttering.
We previously had an implementation of CSS animations that could run
fully on the UI thread, without having to call back into webkit.
We turned it off because there was still some glitches, and calling
into webkit seemed to work well enough -- but as we can see, even
if that's the case in general, edge cases still benefit from running
the animations outside of webkit.
The CL fixes the remaining glitches we had (mostly, it was the
non support of fillMode) and re-enable our CSS animations implementation.
bug:5297559
Change-Id: I1f00bc060a76c9dfd55bd6d8ae85d5d6da68ddb5
Diffstat (limited to 'Source/WebCore/platform/wx/SharedBufferWx.cpp')
0 files changed, 0 insertions, 0 deletions