I've tried quite hard to narrow this down to a single very simple test case, but it remains very slippery.  It seems to depend very much on context.  For example, if I trim things down so that the only gl call each frame is a gl.Clear() it will go slowly if there has been significant activity earlier in the session (see below ***).
However, if I do more significant graphics including gl.Clear() it will still run at 90fps in VR.  see: http://programbits.co.uk/xyz/triv1.html

~~~~ (***)
e.g using  http://programbits.co.uk/xyz/xyz.html, in VR at high res, uncheck all visibles.  Frame rate 90fps.
In developer tools set renderer.autoClear=true; frame rate drops to 45fps.
Trace from developer tools below.  Gldebug.frame() traces all gl calls for a single frame.

.................. running with no visible graphics at 90fps
Gldebug.frame()
undefined
renderer.autoClear=true
true
.................. no runs with no visible graphics at 45fps
Gldebug.frame()
undefined
gldebug.js:95 1673 ">> gldebug wrapped clear  (17664)            O (0 0x0)"

Thanks for filing.

OpenVR does work to ensure a consistent framerate, preferring 45fps to sometimes dipping below 90fps.  This means if we occasionally miss a frame we'll drop down to 45.  Various things like a poorly timed garbage collection, layout, or other work on the main thread could cause us to miss a frame.  I'm not sure what will trigger us to go back to 90 after openvr is throttling.

There is some room for optimization here (a few extra copies and a few synchronous calls), and some potential for prioritizing work to ensure we hit frame deadlines.

We could do some work to allow multiple frames in progress to allow parallelism between GPU work and JavaScript work (being careful to minimize latency).

Thanks for the helpful response.  A few comments.

1. We are going through the same OpenVR with Firefox and without the slowdowns.  

2. I thought OpenVR only dropped to regular 45fps if 'allow interleaved projection' was checked?  I have been running with 'allow asynchronous reprojection'.  Either way, or without either, it should be able to keep a steady 90fps.

3. I don't think parallelism is an issue here as there is almost no CPU work and very little GPU work involved before we see the slowdown.  Paralellism is clearly very important in more stressed situations.

4. I forgot to mention in the original post that this is probably related to the performance issues covered towards the end of the thread https://github.com/toji/chrome-webvr-issues/issues/156, (starting at 'part of the reason').  As klausw commented in that thread we should probably have opened that as an issue here.  I thought that maybe the apparent relationship between performance issues and canvas resolution might help resolve that.

Finally found the issue; or at least a significant point towards it.
It depends on whether alpha is set on the canvas rendering context.

Compare:
http://programbits.co.uk/xyz/triv.html?ca.alpha=true     slow in VR
http://programbits.co.uk/xyz/triv.html?ca.alpha=false    fast in VR
In each case, start then click the 1.4 radio button.

For three.js, alpha defaults to false, which gives slow VR.
if no contextAttribute is given on the canvas.getContext('webgl') call you get fast VR.
(I can't find an API to query the attribute values from the context after creation, is there one?)

To get the context creation attributes that a context was actually created with you call gl.getContextAttributes(); Note that in the case of things like antialiasing the values returned from that call may be different than the ones passed to getContext() if the system doesn't support the requested feature.

To clarify, you say with the links that `alpha: false` gives better performance, but then say that three.js uses that as the default which gives slow performance. Are you observing that `alpha: false` is the fast path or the slow path?

Thank you for pointing me to gl.getContextAttributes() ... not sure how I missed it.

I apologize for a very unhelpful stupidity above.  I should have said
http://programbits.co.uk/xyz/triv.html?ca.alpha=true     FAST in VR
http://programbits.co.uk/xyz/triv.html?ca.alpha=false    SLOW in VR
(I hope you observe the same)

Obviously, ideally Canary will go fast with either value of alpha.

By the way, in case it is easier for you to work with
https://webvr.info/samples/03-vr-presentation.html also explicitly sets alpha:false and goes slowly,
but goes faster if you break in developer tools and overwrite glAttribs with alpha:true.

In the latest canary version Version 65.0.3316.0 (Official Build) canary (64-bit) setting value of "alpha: true" results in black screen inside htc vive.

I am on 65.0.3316.0 (Official Build) canary (64-bit) with settings as below,
and seeing image both on Vive and on monitor.

{
  "alpha": true,
  "depth": true,
  "stencil": false,
  "antialias": true,
  "premultipliedAlpha": false,
  "preserveDrawingBuffer": true,
  "powerPreference": "default",
  "failIfMajorPerformanceCaveat": false,
  "logarithmicDepthBuffer": false
}

In case it helps, the following are the chrome://flags I have explicitly enabled

Override software rendering list
Overrides the built-in software rendering list and enables GPU-acceleration on unsupported system configurations. – Mac, Windows, Linux, Chrome OS, Android
#ignore-gpu-blacklist

Gamepad Extensions
Enabling this option allows web applications to access experimental extensions to the Gamepad APIs. – Mac, Windows, Linux, Chrome OS, Android
#enable-gamepad-extensions

WebVR
Allow web applications to access experimental Virtual Reality functionality via the WebVR 1.1 API. This feature will eventually be replaced by the WebXR Device API. Warning: Enabling this will also allow WebVR content on insecure origins to access these powerful APIs, and may pose a security risk. – Mac, Windows, Linux, Chrome OS, Android
#enable-webvr

WebVR experimental rendering optimizations
Experimental rendering path optimizations for WebVR. – Mac, Windows, Linux, Chrome OS, Android
#webvr-experimental-rendering

WebXR Device API
Allow web applications to access experimental APIs to interact with Virtual Reality (VR) and Augmented Reality (AR) devices. – Mac, Windows, Linux, Chrome OS, Android
#webxr

OpenVR hardware support
If enabled, Chrome will use OpenVR devices for VR. – Windows
#openvr

I have also enabled & checked with the same flag for chrome. I have tried this two examples:

1. https://threejs.org/examples/?q=vive#webvr_vive
2. https://webvr.info/samples/03-vr-presentation.html

I have passed same parameters value to WebGLRenderer. Here are the observations from link 1:
1. alpha: true,preserveDrawingBuffer: true, nothing is hmd but i can see & track the movement in canary.
2. alpha: true,preserveDrawingBuffer: false nothing in hmd, nothing in canary
3. alpha: false,preserveDrawingBuffer: true, nothing is hmd but i can see & track the movement in canary.
4. alpha: false,preserveDrawingBuffer: false, I can see in hmd but nothing in scene.

Is there anything else i need to do? All the flags that you mentioned are enabled.

Unable to check this issue from ET/Inhouse team as we are seeing VR not found error on navigating to https://threejs.org/examples/?q=vive#webvr_vive. 

As ET/Inhouse team doesn't have VR headset to test this issue. Could someone from MTV take a look into this issue.

Thanks!

behaving almost sensibly for me (90fps with no screen problems in all 4 settings is what I think we should see)
Comments and some other details that may highlight relevant difference between our setups.

1. alpha: true,preserveDrawingBuffer: true,    both, 60fps
2. alpha: true,preserveDrawingBuffer: false    hmd ok, frozen on screen, 90fps
3. alpha: false,preserveDrawingBuffer: true,   both ok, 60 fps 
4. alpha: false,preserveDrawingBuffer: false,  hmd ok, frozen on screen, 45fps 

SteamVR version 5 Dec 2017, Nvidia 388.71.
Desktop 1080 (no complications from dual graphics)
Have you experimented with SteamVR settings?

~~~
Have you tried Firefox?
1. alpha: true,preserveDrawingBuffer: true,    all ok, 90fps
2. alpha: true,preserveDrawingBuffer: false    nothing in hmd
3. alpha: false,preserveDrawingBuffer: true,   nothing in hmd
4. alpha: false,preserveDrawingBuffer: false,  all ok 90

~~~
useful copy/paste console debug line for both at breakpoint in  https://webvr.info/samples/03-vr-presentation.html line 126
glAttribs = { alpha: false,preserveDrawingBuffer: true}; document.getElementById('presenting-message').style.height = '50px'

I have tried with the three.js example in firefox & everything is okay for any value of alpha & preserveDrawingBuffer. I can see both in hmd & in browser.

SteamVR version 6 jan 2018, Nvidia Geforce GTX 1060 version 388.13.
windows 10

what do you mean by experimenting with steamVR setting? I will update my graphics card driver & check again tomorrow.

@mamun4.  Settings such as 'Performance: Allow asynchronous reprojection'.
Most importantly 'Developer: Direct Mode'
I don't really expect they will make a difference, but there clearly is a difference somewhere we haven't managed to track down.

bilorr@, can you take a look?

Did some profiling, and I'm seeing an expensive glClear in ANGLE while we are presenting.  glClear is almost taking a full core, about 20ms per call.

This appears to happen because checking the framebuffer status inside glClear will sometimes allocate a new d3d11 texture, and set its subresource data.  The expensive CPU work is filling the initial texture's color in CPU memory before uploading to GPU.  It is interesting that we even bother with setting the initial data when we are about to clear the texture.

Stack of expensive memset:
chrome_child.dll!gpu::gles2::GLES2DecoderPassthroughImpl::HandleClear
chrome_child.dll!gpu::gles2::GLES2DecoderPassthroughImpl::DoClear
chrome_child.dll!gl::TraceGLApi::glClearFn
libglesv2.dll!gl::Clear
libglesv2.dll!gl::ValidateClear
libglesv2.dll!gl::Framebuffer::checkStatus
libglesv2.dll!gl::Framebuffer::checkStatusImpl
libglesv2.dll!rx::Framebuffer11::syncState
libglesv2.dll!rx::`anonymous namespace'::UpdateCachedRenderTarget
libglesv2.dll!gl::FramebufferAttachmentObject::getAttachmentRenderTarget
libglesv2.dll!rx::TextureD3D::getAttachmentRenderTarget
libglesv2.dll!rx::TextureD3D_2D::getRenderTarget
libglesv2.dll!rx::TextureD3D::ensureRenderTarget
libglesv2.dll!rx::TextureD3D_2D::initializeStorage
libglesv2.dll!rx::TextureD3D_2D::updateStorage
libglesv2.dll!rx::TextureD3D_2D::updateStorageLevel
libglesv2.dll!rx::TextureD3D::commitRegion
libglesv2.dll!rx::Image11::copyToStorage
libglesv2.dll!rx::Image11::getStagingTexture
libglesv2.dll!rx::Image11::createStagingTexture
libglesv2.dll!rx::d3d11::GenerateInitialTextureData
libglesv2.dll!memset

I'm not yet sure why this doesn't happen when not presenting.  Perhaps copying the texture along with WebGL optimizations to mark the texture as discardable could make ANGLE think that the texture is dirty?

More investigation needed to determine the issue, but making progress.

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

commit 593976ada0162683f152d1acaad33733044773ab
Author: Bill Orr <billorr@chromium.org>
Date: Tue Feb 06 03:38:59 2018

Fix issue where some sites render at only 45fps in WebVR on Windows

The issue here is that we weren't recycling color buffers, and creation
of new buffers can be slow (in the order of 20ms) depending on color format.

BUG= 798112 

Change-Id: Ibecc5815f5386d13bc776cb85e2aee20756964d6
Reviewed-on: https://chromium-review.googlesource.com/899957
Commit-Queue: Bill Orr <billorr@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
Reviewed-by: Klaus Weidner <klausw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534613}
[modify] https://crrev.com/593976ada0162683f152d1acaad33733044773ab/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
[modify] https://crrev.com/593976ada0162683f152d1acaad33733044773ab/third_party/WebKit/Source/modules/vr/VRDisplay.h
[modify] https://crrev.com/593976ada0162683f152d1acaad33733044773ab/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
[modify] https://crrev.com/593976ada0162683f152d1acaad33733044773ab/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.h
[modify] https://crrev.com/593976ada0162683f152d1acaad33733044773ab/third_party/WebKit/Source/modules/xr/XRFrameProvider.cpp
[modify] https://crrev.com/593976ada0162683f152d1acaad33733044773ab/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/593976ada0162683f152d1acaad33733044773ab/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h
[modify] https://crrev.com/593976ada0162683f152d1acaad33733044773ab/third_party/WebKit/Source/platform/graphics/gpu/XRFrameTransport.cpp
[modify] https://crrev.com/593976ada0162683f152d1acaad33733044773ab/third_party/WebKit/Source/platform/graphics/gpu/XRFrameTransport.h

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

commit 28dcdcf5110246011a2a6488a44fa65ea7434190
Author: Kenneth Russell <kbr@chromium.org>
Date: Thu Feb 08 18:10:05 2018

Revert "Fix issue where some sites render at only 45fps in WebVR on Windows"

This reverts commit 593976ada0162683f152d1acaad33733044773ab.

Reason for revert: caused webgl2_conformance_gl_tests to reliably fail on chromium.gpu.fyi. See  http://crbug.com/810411  .

Original change's description:
> Fix issue where some sites render at only 45fps in WebVR on Windows
> 
> The issue here is that we weren't recycling color buffers, and creation
> of new buffers can be slow (in the order of 20ms) depending on color format.
> 
> BUG= 798112 
> 
> Change-Id: Ibecc5815f5386d13bc776cb85e2aee20756964d6
> Reviewed-on: https://chromium-review.googlesource.com/899957
> Commit-Queue: Bill Orr <billorr@chromium.org>
> Reviewed-by: Kenneth Russell <kbr@chromium.org>
> Reviewed-by: Brandon Jones <bajones@chromium.org>
> Reviewed-by: Klaus Weidner <klausw@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#534613}

TBR=kbr@chromium.org,bajones@chromium.org,klausw@chromium.org,billorr@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  798112 ,  810411 
Change-Id: Ic55f7881706bbe66fb52d41fd32634d6da312bd5
Reviewed-on: https://chromium-review.googlesource.com/908948
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535442}
[modify] https://crrev.com/28dcdcf5110246011a2a6488a44fa65ea7434190/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
[modify] https://crrev.com/28dcdcf5110246011a2a6488a44fa65ea7434190/third_party/WebKit/Source/modules/vr/VRDisplay.h
[modify] https://crrev.com/28dcdcf5110246011a2a6488a44fa65ea7434190/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
[modify] https://crrev.com/28dcdcf5110246011a2a6488a44fa65ea7434190/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.h
[modify] https://crrev.com/28dcdcf5110246011a2a6488a44fa65ea7434190/third_party/WebKit/Source/modules/xr/XRFrameProvider.cpp
[modify] https://crrev.com/28dcdcf5110246011a2a6488a44fa65ea7434190/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/28dcdcf5110246011a2a6488a44fa65ea7434190/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h
[modify] https://crrev.com/28dcdcf5110246011a2a6488a44fa65ea7434190/third_party/WebKit/Source/platform/graphics/gpu/XRFrameTransport.cpp
[modify] https://crrev.com/28dcdcf5110246011a2a6488a44fa65ea7434190/third_party/WebKit/Source/platform/graphics/gpu/XRFrameTransport.h

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

commit f0a174e7dcf9536cf55df68a73a936fcef57c5f5
Author: Bill Orr <billorr@chromium.org>
Date: Thu Feb 08 21:04:18 2018

Reland "Fix issue where some sites render at only 45fps in WebVR on Windows"

This reverts commit 28dcdcf5110246011a2a6488a44fa65ea7434190.

Reason for revert: This revert didn't fix the bots we were hoping it would fix.

Original change's description:
> Revert "Fix issue where some sites render at only 45fps in WebVR on Windows"
> 
> This reverts commit 593976ada0162683f152d1acaad33733044773ab.
> 
> Reason for revert: caused webgl2_conformance_gl_tests to reliably fail on chromium.gpu.fyi. See  http://crbug.com/810411  .
> 
> Original change's description:
> > Fix issue where some sites render at only 45fps in WebVR on Windows
> > 
> > The issue here is that we weren't recycling color buffers, and creation
> > of new buffers can be slow (in the order of 20ms) depending on color format.
> > 
> > BUG= 798112 
> > 
> > Change-Id: Ibecc5815f5386d13bc776cb85e2aee20756964d6
> > Reviewed-on: https://chromium-review.googlesource.com/899957
> > Commit-Queue: Bill Orr <billorr@chromium.org>
> > Reviewed-by: Kenneth Russell <kbr@chromium.org>
> > Reviewed-by: Brandon Jones <bajones@chromium.org>
> > Reviewed-by: Klaus Weidner <klausw@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#534613}
> 
> TBR=kbr@chromium.org,bajones@chromium.org,klausw@chromium.org,billorr@chromium.org
> 
> # Not skipping CQ checks because original CL landed > 1 day ago.
> 
> Bug:  798112 ,  810411 
> Change-Id: Ic55f7881706bbe66fb52d41fd32634d6da312bd5
> Reviewed-on: https://chromium-review.googlesource.com/908948
> Reviewed-by: Kenneth Russell <kbr@chromium.org>
> Commit-Queue: Kenneth Russell <kbr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#535442}

TBR=kbr@chromium.org,bajones@chromium.org,klausw@chromium.org,billorr@chromium.org

Change-Id: If662a6b24faa6151487bae21b852de2b6b2741c9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  798112 ,  810411 
Reviewed-on: https://chromium-review.googlesource.com/909748
Reviewed-by: Bill Orr <billorr@chromium.org>
Commit-Queue: Bill Orr <billorr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535512}
[modify] https://crrev.com/f0a174e7dcf9536cf55df68a73a936fcef57c5f5/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
[modify] https://crrev.com/f0a174e7dcf9536cf55df68a73a936fcef57c5f5/third_party/WebKit/Source/modules/vr/VRDisplay.h
[modify] https://crrev.com/f0a174e7dcf9536cf55df68a73a936fcef57c5f5/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
[modify] https://crrev.com/f0a174e7dcf9536cf55df68a73a936fcef57c5f5/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.h
[modify] https://crrev.com/f0a174e7dcf9536cf55df68a73a936fcef57c5f5/third_party/WebKit/Source/modules/xr/XRFrameProvider.cpp
[modify] https://crrev.com/f0a174e7dcf9536cf55df68a73a936fcef57c5f5/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/f0a174e7dcf9536cf55df68a73a936fcef57c5f5/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h
[modify] https://crrev.com/f0a174e7dcf9536cf55df68a73a936fcef57c5f5/third_party/WebKit/Source/platform/graphics/gpu/XRFrameTransport.cpp
[modify] https://crrev.com/f0a174e7dcf9536cf55df68a73a936fcef57c5f5/third_party/WebKit/Source/platform/graphics/gpu/XRFrameTransport.h

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

commit 82ff1d570d7a0369998d42fa7d12961b8835f75f
Author: Brandon Jones <bajones@chromium.org>
Date: Thu Feb 08 22:08:00 2018

Enabled WebXR to recycle XRWebGLLayer backbuffers

This should yield similar performance improvments to recent changes
billorr@ made to WebVR to take advatage of the same pattern. Not
implemented for magic window yet, primarily because WebGL's ImageBitmap
path doesn't allow for recycling images either.

Bug:  798112 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I09b206536d82604539ceb57004058c091c9f32cc
Reviewed-on: https://chromium-review.googlesource.com/907739
Commit-Queue: Brandon Jones <bajones@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Bill Orr <billorr@chromium.org>
Reviewed-by: Klaus Weidner <klausw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535540}
[modify] https://crrev.com/82ff1d570d7a0369998d42fa7d12961b8835f75f/third_party/WebKit/Source/modules/xr/XRFrameProvider.cpp
[modify] https://crrev.com/82ff1d570d7a0369998d42fa7d12961b8835f75f/third_party/WebKit/Source/modules/xr/XRWebGLLayer.cpp
[modify] https://crrev.com/82ff1d570d7a0369998d42fa7d12961b8835f75f/third_party/WebKit/Source/modules/xr/XRWebGLLayer.h
[modify] https://crrev.com/82ff1d570d7a0369998d42fa7d12961b8835f75f/third_party/WebKit/Source/platform/graphics/gpu/XRWebGLDrawingBuffer.cpp
[modify] https://crrev.com/82ff1d570d7a0369998d42fa7d12961b8835f75f/third_party/WebKit/Source/platform/graphics/gpu/XRWebGLDrawingBuffer.h