News for hackers. Stuff that matters.
Re:Firefox 55: WebVR and more by TD-Linux on Tuesday August 08, 2017 @08:51PM (#14964566)
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/

Re:Firefox 55: WebVR and more by mncharity on Tuesday August 08, 2017 @09:46PM (#14964853)
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.”