4 ms·

This wouldn't even be worth commenting on it's so normal, except that Mozilla has a strong history of getting all their stuff working on all platforms before le

This wouldn't even be worth commenting on it's so normal, except that Mozilla has a strong history of getting all their stuff working on all platforms before letting a release drop, so as much as I love VR, Mozilla, and Linux, I'm going to sit here and pout until I can do my thing on my tower. <3

mncharity 9y ago
> 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-virtual-reality-to-all-firefox-users/ 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/ https://hacks.mozilla.org/2017/06/announcing-webvr-on-mac/ [3] https://github.com/OSVR/OSVR-Docs/issues/83 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_anyone_with_steam_running_fine_with/djugskl/ 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/ https://webvr.rocks/ doesn't even bother to have a linux column.
- kuschku 9y ago
  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.
  - hsivonen 9y ago
    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.
    - kuschku 9y ago
      That used to be one, but not with the Quantum compositor, which already can use frames from the GPU's memory.
- TD-Linux 9y ago
  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.”
hobarrera 9y ago
Not even close. Mozilla has been windows-centric for years. While they've kept Linux support really well, and most features make it, windows tends to be the first platform they address. Under the hook, it's extra windowsy. For example, they just dump config/cache/etc in a way similar to what's done on windows, and refused to support the XDG spec, which most desktop apps use.
bigbugbag 9y ago
> Mozilla has a strong history of getting all their stuff working on all platforms before letting a release drop I would like to see some substantation of this claim, my experience as linux user for 20 years is that firefox on linux is a second class citizen and mozilla developers often answer linux specific bugs by "wontfix, not a big enough portion of our users, would be a waste of resources".

mncharity 9y ago

> 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-virtual-reality-to-all-firefox-users/ 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/ https://hacks.mozilla.org/2017/06/announcing-webvr-on-mac/ [3] https://github.com/OSVR/OSVR-Docs/issues/83 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_anyone_with_steam_running_fine_with/djugskl/ 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/ https://webvr.rocks/ doesn't even bother to have a linux column.

kuschku 9y ago
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.
- hsivonen 9y ago
  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.
  - kuschku 9y ago
    That used to be one, but not with the Quantum compositor, which already can use frames from the GPU's memory.
TD-Linux 9y ago
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.”

hobarrera 9y ago

Not even close. Mozilla has been windows-centric for years. While they've kept Linux support really well, and most features make it, windows tends to be the first platform they address. Under the hook, it's extra windowsy. For example, they just dump config/cache/etc in a way similar to what's done on windows, and refused to support the XDG spec, which most desktop apps use.

bigbugbag 9y ago

> Mozilla has a strong history of getting all their stuff working on all platforms before letting a release drop I would like to see some substantation of this claim, my experience as linux user for 20 years is that firefox on linux is a second class citizen and mozilla developers often answer linux specific bugs by "wontfix, not a big enough portion of our users, would be a waste of resources".