[webvr] What not a shared WebVR library similar to ANGLE?

Florian Bösch pyalot at gmail.com
Fri Sep 2 00:28:30 UTC 2016

I forgot to explain that the idea would be for the compatibility layers
frontend to *be* the standard, and that no further translation to the WebVR
standard would be needed beyond hooking up its endpoints. That would
(possibly) avoid the protracted update cycle that WebGL is currently
engaged in, or at least streamline it.

On Fri, Sep 2, 2016 at 2:20 AM, Florian Bösch <pyalot at gmail.com> wrote:

> Not to diminish the accomplishment of ANGLE being a central component of
> WebGL, I feel it should be mentioned that it's also been the source of
> cross-vendor bugs that wouldn't exist quite this way in a more heterogenous
> implementation environment. And while it's a great waste of time for
> everybody to write everything, it is also a great source of resilience
> against cross vendor/ecosystem bugs.
> I'm not up to date on the state of OSVR and vendor specific SDKs, but I
> also don't think it's quite comparable to ANGLE.
> ANGLE in a nutshell uses a standardized set of APIs offered by the
> operating system against a system driver. The evolution of both the backend
> and frontend APIs followed a well documented and predictable process.
> Nevertheless even with the ANGLE compatibility layer in place, an update
> to WebGL has proven to be an extraordinarily difficult process, and it is
> still, and will be for quite some time, be stuck at its first iteration
> (give or take the odd extension).
> A VR-SDK is not a driver and a standard set of APIs. They're not following
> a well documented and specified revisioning process, they're not system
> drivers, they don't offer a standardized way to access the hardware and
> they're not coming installed with the operating system. I'm sure some of
> these things will change eventually, but they won't change tomorrow.
> OSVR itself has to service the ecosystem of devices it "natively" supports
> first, and everything else second. This means that new features that Oculus
> and Vive think up, and put into their sdk, might not be available in OSVR
> for quite some time, if ever.
> I don't see how that improves the situation/drawbacks of having a single
> compatibility layer that reflects a state of affairs as it existed quite
> some time (years) ago. I do think that a suitable compatibility layer has
> the following characteristics (just my opinion of course):
>    - It is VR-vendor neutral
>    - It provides an extension mechanism to use VR-vendor specific
>    features before they've been present in hardware/SDKs for a decade
>    - It provides suitable ways to detect the capabilities/extensions of
>    the presently connected device. In web parlance, avoid UA detection but
>    practice feature detection.
>    - Its core API (the lowest common denominator between VR-devices)
>    follows a standard process
>    - Extensions follow an extension evolution process
> This has been after all a fairly successful recipe for the GL family of
> APIs, and is somewhat adopted by DirectX in its later incarnations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/web-vr-discuss/attachments/20160902/92a9d84a/attachment.html>

More information about the web-vr-discuss mailing list