[webvr] Ultra-slow getPose() with VIVE on some machines but not others?
ben at exocortex.com
Thu Sep 29 00:46:46 UTC 2016
We have successfully worked around the bug by tracing each WebGL /
WebVR call and comparing it to the reference demos in ThreeJS. Once
we changed the parameters and call order to the ThreeJS VIVE demo
ordering it works on the problematic machines. Thus there is a WebGL
/ WebVR call order issue that causes getPose() to be super slow that
arises on some machines and not others.
Ben Houston (Cell: 613-762-4113, Skype: ben.exocortex, Twitter: @exocortexcom)
https://Clara.io - Online 3D Modeling and Rendering
On Wed, Aug 31, 2016 at 12:34 PM, Ben Houston <ben at exocortex.com> wrote:
> Thanks for your feedback. I'm tracking the issue here:
> On Wed, Aug 31, 2016 at 12:01 PM, Brandon Jones <bajones at google.com> wrote:
>> I've heard of similar issues from other developers but have yet to come
>> across them myself. I'd be very interested in hearing what you find!
>> On Wed, Aug 31, 2016 at 8:30 AM Ben Houston <ben at exocortex.com> wrote:
>>> Hi all,
>>> We are running into a situation where we are getting a very slow
>>> getPose() in our WebVR stuff with the VIVE but only on some machines,
>>> on others it operates perfectly.
>>> They seem nearly identical but there are likely differences. Both are
>>> running NVIDIA GeForce 980s with the latest driver and running the
>>> same latest build of Chromium WebVR browser.
>>> Basically we have a test page here: http://exocortex.github.io/vr
>>> I have a captured from the Chrome profiler showing the speed issue
>>> here - 400ms per getPose() calls:
>>> Interestingly, we are using the ThreeJS VRControls, and the latest
>>> ThreeJS VR demo that use this code do not exhibit it on the
>>> problematic machines. Sketchfab's VR stuff also doesn't exhibit this
>>> behavior. I have confirmed that Sketchfab's VR code is very similar
>>> and relies upon getPose as well.
>>> Thus I am starting to think there is an order of operations issue at
>>> play that is interacting with machine specific setups? Could there be
>>> VIVE SDK versions at play? But it is still weird it affects our VR
>>> and not the ThreeJS VR demos.
>>> I guess our next step is to try and do a binary search of the
>>> differences between our usage and the ThreeJS VR demos until we find
>>> the change that causes this.
>>> Best regards,
>>> Ben Houston
>>> web-vr-discuss mailing list
>>> web-vr-discuss at mozilla.org
More information about the web-vr-discuss