diff options
| author | Nicolas Roard <nicolas@android.com> | 2011-03-03 10:16:31 -0800 |
|---|---|---|
| committer | The Android Automerger <android-build@android.com> | 2011-03-03 12:34:30 -0800 |
| commit | e70222ba5aafd13d88b64d27a2ea4d5dbcd7ade6 (patch) | |
| tree | 51f05c77cdc96bea12addc5e6993473a7a50365f /Tools/Scripts/webkitpy/layout_tests/run_webkit_tests_unittest.py | |
| parent | 1a87f05e2263f9e256d65d4a61f9cd7b5d53e72b (diff) | |
| download | external_webkit-e70222ba5aafd13d88b64d27a2ea4d5dbcd7ade6.zip external_webkit-e70222ba5aafd13d88b64d27a2ea4d5dbcd7ade6.tar.gz external_webkit-e70222ba5aafd13d88b64d27a2ea4d5dbcd7ade6.tar.bz2 | |
DO NOT MERGE : Cherry-pick of 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: Iae50737b6d3202a8a0d3ec6d4a5261fe1b6d1b3f
Diffstat (limited to 'Tools/Scripts/webkitpy/layout_tests/run_webkit_tests_unittest.py')
0 files changed, 0 insertions, 0 deletions