Fixes: 29072773
By using computeFrameTime AnimationContext would
potentially end up modifying the latest vsync if
a very-slow frame was received from the UI thread.
This could potentially desync animations that were
RT & UI thread 'synchronized', but more significantly
it would confuse the swap chain which tries to only
draw one frame per vsync causing unneccessary frame
drops.
Change-Id: Ibd2ec3157ce32fee1eec8d56837c45a35e622895
Adds remaining missing overrides and nullptr usages, missed due to
an extreme failure in tool usage.
Change-Id: I56abd72975a3999ad13330003c348db40f59aebf
Remove Clang cutout for unused parameters. Fix warnings.
Remove Clang cutout for deprecated Skia function usage. Has been
fixed in the L push.
Change-Id: I7ea073ff67127cc1e14e798b655e2c50615fe8e7
Bug: 17372309
AnimationContext::startFrame() happens both with and without
the UI thread lock. Pass the TraversalMode into it so
that ThreadedRenderer's subclass can correctly decide
when it is safe to push over mPendingAnimatingRenderNodes, as doing
so outside of the lock is Very Bad.
Change-Id: Ife5dd3a2b46b0a207cd9234c159a674afdbf5efd
Bug: 17372309
Fixes a case where UI thread and RT thread both used the same method
which wasn't safe for either of them.
Adds additional assertions & logging in unusual circumstances to
try and track down where the issue is occuring from.
Change-Id: I93d31a6fd0c5927259b67bdf96a475944226eee6