Currently, VrShellGl does its own timing calculations, using timebase + num_intervals * vsync_interval to get successive VSync time points.

However, currently vsync_interval is implemented as a base::TimeDelta which has microsecond resolution, with ~1/3 (or 2/3) of a microsecond error. After one minute of presentation, num_intervals is 3600, and the error gets amplified to ~1ms, and after a few minutes the time used will be out of sync with actual vsync time.

Also, we're currently using getSystemService(Context.WINDOW_SERVICE)).getDefaultDisplay().getRefreshRate() for the vsync interval. We should confirm that this number is itself sufficiently accurate if extrapolating future vsync times.

Consider running VrShellDelegate's choreographer.postFrameCallback() continuously and periodically refreshing VrShellGl's vsync timing. This doesn't need to be propagated every frame, just often enough to ensure that any drift remains acceptable.