3 ms·

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 composit

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 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/ https://keithp.com/blogs/DRM-lease/

mncharity 9y ago
Here is the DocOk/Vrui post on latency, A Trip Down the Graphics Pipeline (2014) http://doc-ok.org/?p=1057 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 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.”

mncharity 9y ago

Here is the DocOk/Vrui post on latency, A Trip Down the Graphics Pipeline (2014) http://doc-ok.org/?p=1057 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 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.”