Avoid re-calculating vsync mid-frame

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

libs/hwui/AnimationContext.cpp

@@ -63,7 +63,7 @@ void AnimationContext::startFrame(TreeInfo::TraversalMode mode) {
         mCurrentFrameAnimations.mNextHandle = head;
         head->mPreviousHandle = &mCurrentFrameAnimations;
     }
-    mFrameTimeMs = mClock.computeFrameTimeMs();
+    mFrameTimeMs = ns2ms(mClock.latestVsync());
 }
 
 void AnimationContext::runRemainingAnimations(TreeInfo& info) {

libs/hwui/renderthread/TimeLord.cpp

@@ -43,10 +43,6 @@ nsecs_t TimeLord::computeFrameTimeNanos() {
     return mFrameTimeNanos;
 }
 
-nsecs_t TimeLord::computeFrameTimeMs() {
-    return nanoseconds_to_milliseconds(computeFrameTimeNanos());
-}
-
 } /* namespace renderthread */
 } /* namespace uirenderer */
 } /* namespace android */

libs/hwui/renderthread/TimeLord.h

@@ -34,7 +34,6 @@ public:
     // returns true if the vsync is newer, false if it was rejected for staleness
     bool vsyncReceived(nsecs_t vsync);
     nsecs_t latestVsync() { return mFrameTimeNanos; }
-    nsecs_t computeFrameTimeMs();
     nsecs_t computeFrameTimeNanos();
 
 private: