Comment by mncharity | Hacker News Reader

Comment by mncharity | Hacker News Reader

Parent Full thread

> Mozilla has a strong history of getting all their stuff working on all platforms

That mindset has been starkly absent with WebVR. As in...

* "Mozilla Brings Virtual Reality to all Firefox Users" means "WebVR will ship on by default for all Windows users" [1] https://blog.mozilla.org/blog/2017/06/01/mozilla-brings-virt...

* "Announcing WebVR on Mac via Firefox Nightly"[2] says "web developers can build and test content on their preferred platform, whether it’s Windows, MacOS, or Linux (also available!)", where "available" means "crashes within seconds"[3] for almost a year, with no fix in sight. [2] https://hacks.mozilla.org/2017/06/announcing-webvr-on-mac/ [3] https://github.com/OSVR/OSVR-Docs/issues/83

* The alleged blocker, "direct mode", is needed to get acceptable performance on Windows... but not on linux. [4] https://www.reddit.com/r/Vive/comments/6lepou/linux_gamers_a...

Once upon a time, Microsoft would create Windows-only web extensions, to the detriment of the web. Nowadays, Mozilla does it for them.

A good rule of thumb for WebVR has been that there's always an unstated "on Windows", and anything said about non-Windows platforms working, is at best misleading. Especially anything said by Mozilla - it's been very bizarre.

https://webvr.rocks/ doesn't even bother to have a linux column.

The issue without "Direct Mode" is latency, as your link says. You need to bypass both the browser compositor and the system compositor. On Linux, most compositors will implement something like Direct Mode (compositor bypass) when you go fullscreen, but it's a bit hit and miss with multimonitor setups. It might fly as a stopgap, though. Here's the tracking bug for WebVR on Linux, if you want to follow progress: https://bugzilla.mozilla.org/show_bug.cgi?id=1310655

Something more directly analogous to "Direct Mode" on Windows are DRM leases, which give direct control over the scanout, rather than simply bypassing the compositor. This isn't possible on Linux at all yet, but Valve is working on it: https://keithp.com/blogs/DRM-lease/

Here is the DocOk/Vrui post on latency, A Trip Down the Graphics Pipeline (2014) http://doc-ok.org/?p=1057 (from which the reddit-linked graphs came).

Highlights include:

> Under a non-compositing window manager, regular double-buffering under OpenGL does not incur undue latency (and there is a window manager hint to tell a compositing manager to grant pass-through to a window).

> At least using the Nvidia graphics driver [...] OpenGL can vsync to any connected display, primary or secondary.

> OpenGL and X Windows allow applications to draw directly into a video controller’s frame buffer, allowing single-buffered rendering and racing the video controller’s scanout. [...] With front buffer rendering, display latency on the Rift DK2 dropped to about 4.3ms

And from Zero-latency Rendering (2015) http://doc-ok.org/?p=1313

> with some new rendering configuration options in Vrui 4.0 I can disable vsync, and render directly into the display window’s front buffer. In other words, I can let these applications “race the beam.”

Not just WebVR. Hardware video decoding was dropped for Linux years ago, never added back. Hardware compositing is only provided in edge cases.

The performance results are ridiculous, you're maxing out an entire processor core just for a 1440p H264 video on Firefox.

For hardware decoding to make sense, there needs to be a way to present the decoded frames in a way that doesn't involve a read-back and that works with the rest of the browser graphics pipeline. That's currently a problem on Linux.

That used to be one, but not with the Quantum compositor, which already can use frames from the GPU's memory.

Reply on news.ycombinator.com