Map the Android VsyncWaiter frame start time to the clock used by fml::TimePoint

[jason-simmons]

The Android Choreographer.doFrame callback provides a timestamp in
the clock used by System.nanoTime. The VsyncWaiter needs to translate
this to a frame start time based on the fml::TimePoint clock
(similar to how VsyncWaiterIOS calculates the frame start time)

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[ColdPaleLight]

Hi, @jason-simmons

Thank you for taking the time out of your busy schedule to solve this problem.

I'm not sure if this change is needed for Android. The following are some of my personal views：

1. The reason why iOS needs to do this is that CADisplayLink.link and CADisplayLink.duration are both in seconds. So it has to do the conversion. But Android does not have this problem.

2. System.nanoTime and DartTimelineTicksSinceEpoch are both based on clock_gettime

• System.nanoTime
  https://android.googlesource.com/platform/libcore/+/master/ojluni/src/main/native/System.c#254
• DartTimelineTicksSinceEpoch（based on OS::GetCurrentMonotonicTicks）
  https://github.com/dart-lang/sdk/blob/e995cb5f7cd67d39c1ee4bdbe95c8241db36725f/runtime/vm/os_android.cc#L147

Thanks

[jason-simmons]

Yes - this is not strictly necessary given the similarity between the clocks used by Choreographer.doFrame and fml::TimePoint.

However, I do think this will help ensure correctness because that similarlity is an implementation detail. If either clock implementation ever changes, then it will be valuable to do an explicit conversion of the timestamp between the two clocks.

[ColdPaleLight]

However, I do think this will help ensure correctness because that similarlity is an implementation detail. If either clock implementation ever changes, then it will be valuable to do an explicit conversion of the timestamp between the two clocks.

That sounds good.

[iskakaushik]

LGTM