Offscreen Canvas rendering doesn't currently work for VR (even if we allow setting an offscreen canvas as the source canvas). Klaus is working on fixing this at the moment, but it's an issue with how our rendering currently works.

Okay, I certainly don't want to duplicate work.

I took a good look at the existing code that presents on Android.  I believe the existing presentation path for OffscreenCanvas can be used quite straitforwardly by VRDisplay. It would just be a matter of creating a CanvasSurfaceLayerBridge owned by the VRDisplay.  Once that is in place, it will be possible to also use this path for the HTMLCanvasElement case, which will be a lot more efficient than the current solution that is based on the fullscreen API.  CanvasSurfaceLayerBridge basically sets up a direct commit path to the UI compositor. This way, presentation can bypass all the blink paint and compositor update overhead.

Yes, I do think Offscreen canvas is good for VR. Offscreen canvas will generate an Image. It will be easy for GVR to draw this Image.

BTW, I am also think about GPU working in an offscreen mode(Not sure if this similar to headless mode). In this mode, render process send framedata into GPU(In new display compositor), GPU composites this framedata into an Image. This Image can be wrapped as EGLImage and then used by VRShell. This may also help to decouple VRShell with android native UI, and make servification of VRShell easier.

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

commit d726dc3033de56a1803cab8db6345de89909d506
Author: junov <junov@chromium.org>
Date: Fri Feb 24 19:57:49 2017

Add OffscreenCanvas to VRSource

This change adds OffscreenCanvas to VRSource by making VRSource
into a union typedef. The internal plumbing is adjusted to handle
a union typedef.  Using an OffscreenCanvas is not functional with this
change, this is just the first step.

BUG=695497

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

[modify] https://crrev.com/d726dc3033de56a1803cab8db6345de89909d506/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
[modify] https://crrev.com/d726dc3033de56a1803cab8db6345de89909d506/third_party/WebKit/Source/modules/vr/VRLayer.idl

The change in #5 just exposes the interface, There's still the whole compositor integration that needs to be figured out.

Passing to klausw for next steps.
@klausw: feel free to assign work to me and/or xlai@ if there is anything we can help with in parallel.

Something I want clarify on top of #c3: 

CanvasSurfaceLayerBridge is not the one responsible for sending the frames to UI compositor. It is a class that ensures the correct creation of SurfaceLayer for the placeholder html canvas. Although it does indeed set up a connection with browser in its constructor, that is mainly to communicate a correct parent frameId and its own surfaceId, in order to set up the SurfaceLayer so that when the frames are processed on browser, the system knows where to display those frames.

Instead, it is the OffscreenCanvasFrameDispatcher (owned by OffscreenCanvas) that does the submission of frames. It uses a common IPC interface called mojo_compositor_frame_sink that's doing the frame submission task. On browser end, the CompositorFrameSinkSupport will be the common class that many services use to handle CompositorFrame.

It is best to reuse the current commit path in OffscreenCanvas. If you intend to add a new path on your own and particularly use the Surfaces, you might want to talk to the MUS team (e.g. fsamuel@ as a contact) about the design; it's quite likely that something you want are already supported.

Removing Blink>WebVR component and assigning to Blink>WebXR