tag 91ff9992f19efd95818d9070c5997da4cad81b20
tagger The Android Open Source Project <initial-contribution@android.com> Fri Apr 08 18:42:11 2011 -0700
object 8519dcd53eb4325b8d2d76c030d0af4503472df7

Android 3.0 release 1.2

commit 8519dcd53eb4325b8d2d76c030d0af4503472df7
author Nicolas Roard <nicolas@android.com> Thu Mar 03 10:16:31 2011 -0800
committer Nicolas Roard <nicolas@android.com> Thu Mar 03 10:28:01 2011 -0800
tree e4f614a2bbaee3b8c7cb87c2e35b54dadc3301fa
parent b715a7c48aa637ebc2832775ea04567c915f6296

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