Correction: the build that was using GL command tracing apparently adds extra glGetError calls that aren't present in a production build.

According to an instrumented production build, there appear to be four glGetError calls per WebVR frame for a simple test page. Not as bad as I originally thought, but are these all necessary?

Source is error_state.cc::GetErrorHandleContextLoss:

https://cs.chromium.org/chromium/src/gpu/command_buffer/service/error_state.cc?type=cs&q=GetErrorHandleContextLoss+file:%5Esrc/+package:%5Echromium$&l=110

GLenum ErrorStateImpl::GetErrorHandleContextLoss() {
  GLenum error = glGetError();
  if (error == GL_CONTEXT_LOST_KHR) {
    client_->OnContextLostError();
    // Do not expose GL_CONTEXT_LOST_KHR, as the version of the robustness
    // extension that introduces the error is not exposed by the command
    // buffer.
    error = GL_NO_ERROR;
  }
  return error;
}

chromium: [INFO:vr_shell_gl.cc(1219)] ;;; pose prediction=65.366ms (js=17.041ms, render=23.268ms), fps=31.4168
chromium: [INFO:error_state.cc(110)] GetErrorHandleContextLoss;;; glGetError
chatty  : uid=10133(org.chromium.chrome) CrGpuMain identical 2 lines
chromium: [INFO:error_state.cc(110)] GetErrorHandleContextLoss;;; glGetError
chromium: [INFO:vr_shell_gl.cc(1219)] ;;; pose prediction=65.578ms (js=18.18ms, render=22.341ms), fps=33.3351
chromium: [INFO:error_state.cc(110)] GetErrorHandleContextLoss;;; glGetError
chatty  : uid=10133(org.chromium.chrome) CrGpuMain identical 2 lines
chromium: [INFO:error_state.cc(110)] GetErrorHandleContextLoss;;; glGetError
chromium: [INFO:vr_shell_gl.cc(1219)] ;;; pose prediction=64.261ms (js=17.685ms, render=21.52ms), fps=33.5862

For reference, here's how I added this logging:

diff --git a/ui/gl/gl_bindings_autogen_gl.h b/ui/gl/gl_bindings_autogen_gl.h
index d077f3eb1c17..9b36e92ab93f 100644
--- a/ui/gl/gl_bindings_autogen_gl.h
+++ b/ui/gl/gl_bindings_autogen_gl.h
@@ -3568,7 +3568,10 @@ class GL_EXPORT GLApi {
 #define glGetBufferPointervRobustANGLE \
   ::gl::g_current_gl_context->glGetBufferPointervRobustANGLEFn
 #define glGetDebugMessageLog ::gl::g_current_gl_context->glGetDebugMessageLogFn
-#define glGetError ::gl::g_current_gl_context->glGetErrorFn
+#define glGetError(x) ({\
+  LOG(INFO) << __FUNCTION__ << ";;; glGetError"; \
+  ::gl::g_current_gl_context->glGetErrorFn(); \
+})
 #define glGetFenceivNV ::gl::g_current_gl_context->glGetFenceivNVFn
 #define glGetFloatv ::gl::g_current_gl_context->glGetFloatvFn
 #define glGetFloatvRobustANGLE \

It's hard to tell without seeing a stack trace. These calls are being made on the GPU process side, rather than the renderer side, so they shouldn't be that expensive. When allocating textures, for example, the only way to know whether the texture allocation succeeded is to call glGetError. In general the command buffer service side shouldn't be making extraneous calls to glGetError, so it's likely that the ones remaining are needed.

Removing Blink>WebVR component and assigning to Blink>WebXR