summaryrefslogtreecommitdiffstats
path: root/MODULE_LICENSE_LGPL
diff options
context:
space:
mode:
authorNicolas Roard <nicolasroard@google.com>2011-10-18 13:07:37 -0700
committerNicolas Roard <nicolasroard@google.com>2011-10-18 13:11:38 -0700
commit8cc0fa17a42ae1dec75fe8ab00d5baa75e46499e (patch)
tree47706253c7de7e041b9c31b1f7c93f5e706a0ad6 /MODULE_LICENSE_LGPL
parenta6d06cef38891b6e39dcbc455f7692f000309ba5 (diff)
downloadexternal_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 'MODULE_LICENSE_LGPL')
0 files changed, 0 insertions, 0 deletions