So this isn't something that's easily fixable. I believe GVR is aware of the issue, I remember reading somewhere that apps get paused, the resumed, then paused again when going to daydream home, and that they're trying to get rid of this thrashing.

My understanding of the issue is that they fade to black for the transition, the previous app gets resumed after having been paused (we exit VR, so this is especially jarring, but any VR app will have this problem), and paused again when the home screen is shown.

We have no way of knowing when we're being paused whether we're going to go to VR home, another VR app, or 2D home. Right now we've optimized for the 2D home case to avoid making 2D clank worse in any way.

Some possible fixes:
- When paused while in VR, draw a black overlay over 2D chrome, and remove this overlay when resuming chrome.
- Don't exit VR when pausing. Instead, when resuming chrome figure out if we came from VR and either exit VR or resume VR.

Both of these fixes could impact 2D clank usage, so we'd need a really good reason to implement either.

Instead of a black overlay, could we screenshot the last frame in VR and
display that until we're resumed?  That would be even less jarring.

Assuming that is possible, how might this impact 2D clank usage?

Screenshotting the last frame in VR would mean that we fade to black, display the screenshot briefly, then display Daydream home - it's still weird and jarring, just slightly less so.

It would impact clank usage in that when the user then goes to launch 2D clank they would see our screenshot of 3D briefly before seeing 2D clank, which would probably also seem weird.

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

commit 73a5c4c765070f73a26c33eb489fca61322c6643
Author: Michael Thiessen <mthiesse@google.com>
Date: Mon Jun 12 18:57:26 2017

VR: Avoid showing 2D UI when returning to Daydream Home

This moves the tearing down of VR UI into onStop instead of onPause.
However, this means we have to handle cases where Chrome pauses without
stopping while in VR. The only case I'm aware of where this is possible
is when the user enters multi-window mode while in VR.

(Even if there are other unhandled cases, the only problem is we keep
showing VR UI where we would prefer not to, and the user would have to
more explicitly exit VR)

Bug:  673528 
Change-Id: Ia890875e1cf813b47443c4bb0883401506e6e55d
Reviewed-on: https://chromium-review.googlesource.com/527379
Commit-Queue: Michael Thiessen <mthiesse@chromium.org>
Reviewed-by: Yash Malik <ymalik@chromium.org>
Reviewed-by: David Trainor <dtrainor@chromium.org>
Cr-Commit-Position: refs/heads/master@{#478701}
[modify] https://crrev.com/73a5c4c765070f73a26c33eb489fca61322c6643/chrome/android/java/src/org/chromium/chrome/browser/ChromeActivity.java
[modify] https://crrev.com/73a5c4c765070f73a26c33eb489fca61322c6643/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrShellDelegate.java
[modify] https://crrev.com/73a5c4c765070f73a26c33eb489fca61322c6643/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrShellImpl.java

 Issue 706033  has been merged into this issue.

Verified in Chrome Canary 61.0.3138.0