Enable creation of offscreen contexts which own their backing surface.

third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp

Index: third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
diff --git a/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp b/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
index 6a68b1659cd48b1b932d67291b0ab8663a738304..131de15a51d63cb20b646ae69b9a3024d7d01ad3 100644
--- a/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
+++ b/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
@@ -47,6 +47,7 @@
 #include "core/layout/LayoutBox.h"
 #include "core/loader/FrameLoader.h"
 #include "core/loader/FrameLoaderClient.h"
+#include "core/origin_trials/OriginTrials.h"
 #include "gpu/command_buffer/client/gles2_interface.h"
 #include "modules/webgl/ANGLEInstancedArrays.h"
 #include "modules/webgl/EXTBlendMinMax.h"
@@ -597,6 +598,17 @@ WebGLRenderingContextBase::createContextProviderInternal(
 
   Platform::ContextAttributes contextAttributes =
       toPlatformContextAttributes(attributes, webGLVersion);
+
+  // If there's a possibility this context may be used with WebVR make sure it
+  // is created with an offscreen surface that can be swapped out for a
+  // VR-specific surface if needed.
+  ExecutionContext* executionContext =
+      canvas ? &canvas->document() : scriptState->getExecutionContext();
+  if (RuntimeEnabledFeatures::webVREnabled() ||
+      OriginTrials::webVREnabled(executionContext)) {
+    contextAttributes.ownOffscreenSurface = true;

[Ken Russell (switch to Gerrit), 2016/11/29 05:09:06]

I haven't reviewed the rest of the patch in depth, but how does this interact
with WebGL's DrawingBuffer and in particular its allocation of its backing
store? I'm concerned about interactions with the code path gated by
DrawingBuffer::shouldUseChromiumImage().

Is the offscreen canvas's storage actually used? Or is the surface's format the
only significant aspect? WebGL's been using the DrawingBuffer for its back
buffer for a long time and it would be a step backward to use the offscreen
context's default framebuffer for anything significant.

Can DrawingBuffer abstract the VR-specific surface, similarly to its
GL_CHROMIUM_image path?

[klausw, 2017/01/05 02:17:43]

For context, the point of this change is to prepare for a WebVR
optimization to let a WebGL DrawingBuffer render directly to a
separately provided Surface, this can then be consumed cross-process
(without copying) as a SurfaceTexture for use with the VR device.

The followup CL https://codereview.chromium.org/2456213 internally
uses SetSurface and requires an output surface that's compatible 
with WebGL drawing, and this generally requires depth buffer and
other features that aren't currently available. This does not work
with offscreen drawing unfortunately, Android's SurfaceTexture 
needs a real surface to draw on.

+  }
+
   Platform::GraphicsInfo glInfo;
   std::unique_ptr<WebGraphicsContext3DProvider> contextProvider;
   if (isMainThread()) {