I was just noticing this myself. I think the issue is the latency between the frames being produced and when we update the layer bounds.

With the current compositor-based rendering new WebGL frames take 2-3 frames to reach the GVR compositor, but when we update the bounds we communicate that to GVR immediately. In practice this would make it so that when updating the bounds the new bounds will retroactively affect a couple of frames before syncing up again. In a sample like this where we update them frequently it manifests as a persistent jitter.

Assuming that is the case I'm not sure it's practical to fix in M56. The planned updates to the rendering pipeline would render this issue moot, but won't be ready till M57. Any short term fix would likely be invasive enough that it would be tough to justify the effort. And in the meantime apps that don't abuse this capability (the sample is a pretty extreme example) will still work pretty well, just a quick flicker on bounds update.

klausw@, your thoughts? 

Unless Klaus disagrees, I'd vote for closing this as WF.

I think fixing this would involve adding a ring buffer of bounds by pose index, similar to the current pose ring buffer. That way, rendering could look up the bounds for the pose in question when rendering it for GVR.

I do think we want to fix this since even without the compositor there's still overlapping frames in the pipeline, and while it should be less extreme I think it would still be noticeable. But I'm not sure if it's feasible for M56.

Tentatively scheduling for M57 then.

Is this likely to happen for M57 or should we punt to M58?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/961dc47e8f5b088debbab559fe81b85f32e9f9e4

commit 961dc47e8f5b088debbab559fe81b85f32e9f9e4
Author: mthiesse <mthiesse@chromium.org>
Date: Fri Jan 27 18:05:56 2017

Allow VRDisplay to specify which frame the layer bounds should be updated at.

BUG= 655722 , 670891 

Review-Url: https://codereview.chromium.org/2612333002
Cr-Commit-Position: refs/heads/master@{#446707}

[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/chrome/browser/android/vr_shell/non_presenting_gvr_delegate.cc
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/chrome/browser/android/vr_shell/non_presenting_gvr_delegate.h
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/chrome/browser/android/vr_shell/vr_shell.cc
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/chrome/browser/android/vr_shell/vr_shell.h
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/chrome/browser/android/vr_shell/vr_shell_gl.cc
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/chrome/browser/android/vr_shell/vr_shell_gl.h
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/device/vr/android/gvr/gvr_delegate.h
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/device/vr/android/gvr/gvr_device.cc
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/device/vr/android/gvr/gvr_device.h
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/device/vr/test/fake_vr_device.cc
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/device/vr/test/fake_vr_device.h
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/device/vr/vr_device.h
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/device/vr/vr_display_impl.cc
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/device/vr/vr_display_impl.h
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/device/vr/vr_service.mojom
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
[modify] https://crrev.com/961dc47e8f5b088debbab559fe81b85f32e9f9e4/third_party/WebKit/Source/modules/vr/VRDisplay.h