diff options
| author | Nicolas Roard <nicolas@android.com> | 2011-03-03 10:16:31 -0800 |
|---|---|---|
| committer | Nicolas Roard <nicolasroard@google.com> | 2011-03-03 10:42:18 -0800 |
| commit | 0c89354f714f107e2d15577c9e415adbe5f03b29 (patch) | |
| tree | fb31ae6e183416b8cfa3ad32789427a536fa7903 /WebCore/css/CSSSelectorList.h | |
| parent | a9f4668988e6d40d01ad07acb702d6fe71d4a5f5 (diff) | |
| download | external_webkit-0c89354f714f107e2d15577c9e415adbe5f03b29.zip external_webkit-0c89354f714f107e2d15577c9e415adbe5f03b29.tar.gz external_webkit-0c89354f714f107e2d15577c9e415adbe5f03b29.tar.bz2 | |
Do not merge: Cherry-pick change I9942e8e4 from master
Wait the remaining of the 60FPS cap delay rather than not paint.
Returning true if called faster than 60FPS means
we are not drawing and ask for the framework to call
us again; this works in general because the framework recopy
the previous framebuffer. But in some cases, it didn't, causing
the webview to flicker. A correct fix would be to introduce
the capping in framework rather than try to doing it in the
webview; in the meantime we will sleep the remaining of the delay
as a workaround, so that we still provide the GPU
benefits we wanted (at >60FPS the GPU was being saturated in
some cases).
bug:3500655
Change-Id: Ibaa1d93e0a13433a2c842b19b58538894fdaa7e4
Diffstat (limited to 'WebCore/css/CSSSelectorList.h')
0 files changed, 0 insertions, 0 deletions