I can't repro this on a Pixel 2 XL running Android O and Chrome 66.0.3336.4, VrCore 1.13 20180201, using Cardboard 2015 viewer type.

Can you try a Cardboard viewer?

Also, is the entire image stuttering, including the static cubes? Or is it just the orbiting cube?

I am able to repro with:
Chrome: 66.0.3336.4
VrCore: 1.2.177372015

Only with Daydream, cardboard is no repro.
Not sure it is helpful but there didn't seem to be anything out of the ordinary when looking at adb logcat | grep "VR" (NOTE I am not really familiar with logcat yet).  See attached logcat.txt file.

It appears the entire image is stuttering including control panel and static cubes.

Deleted: logcat.txt 7.1 KB

logcat.txt 7.1 KB View Download

I can repro the effect using a Cardboard viewer on Canary when using the default "ClientWait" render path. I don't see it when using the experimental "GpuFence" render path.

To make things more mysterious, I also get the stuttering when I add a GLFenceEGL to the GpuFence path - I found this accidentally while working on a modified render path.

My suspicion is that the EGL fences used by the ClientWait mode are somehow interfering with GVR's internal use of fences for detecting when frames are ready for display? Specifically, the issues seem to be happening when the frames are already completely rendered when being submitted to GVR.

Quick update - this does seem to be a Chrome issue and not GVR version related, I'm currently bisecting.

The culprit is r530516 "[vr] Add controller tooltips": https://chromium-review.googlesource.com/875172

Working on a patch now.

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

commit ef56830b31d5b6be1379b956cf4aad9bfa67a1f5
Author: Klaus Weidner <klausw@chromium.org>
Date: Tue Feb 06 03:19:47 2018

Fix out-of-sync poses for WebVR

Change 7332d07490f42ab4fa9ee1a958d9b4e07531b025 "[vr] Add controller
tooltips" changed the OnVSync controller handling to overwrite
render_info_primary_.head_pose, and if this happened in between
DrawFrame and DrawIntoAcquiredFrame it would submit with a wrong
pose, leading to jerky head tracking.

The fix is to always use the saved WebVR pose and ignore the
render_info_primary_.head_pose member.

BUG= 808147 

Change-Id: I1c9b3e9c9e7dad6c9dff2837ae00d46a6fecb915
Reviewed-on: https://chromium-review.googlesource.com/903542
Reviewed-by: Ian Vollick <vollick@chromium.org>
Commit-Queue: Klaus Weidner <klausw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534609}
[modify] https://crrev.com/ef56830b31d5b6be1379b956cf4aad9bfa67a1f5/chrome/browser/android/vr_shell/vr_shell_gl.cc

This should be fixed once the patch makes it to Canary. Looks like it missed the cutoff for today's 6.0.3341.0 by 25 minutes, but should be in the next one.

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

commit 35b411e684c853a1483bd9064e245b04edfb8059
Author: Klaus Weidner <klausw@chromium.org>
Date: Tue Feb 06 19:48:08 2018

Fix VR browsing pose

My fix for the slightly-wrong poses in WebVR unfortunately resulted in
completely wrong (uninitialized) poses for VR browsing mode. Sorry
about that. Use a mode-appropriate pose, and add comments.

BUG= 809608 , 808147 

Change-Id: I2193fd6dfd6d2093b18c16b35680338a64bec5fe
Reviewed-on: https://chromium-review.googlesource.com/905101
Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Commit-Queue: Klaus Weidner <klausw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534758}
[modify] https://crrev.com/35b411e684c853a1483bd9064e245b04edfb8059/chrome/browser/android/vr_shell/vr_shell_gl.cc