3 ms·

> I actually don't care too much about getting WebGL out of the main UI thread. I'm doing WebVR work, Halt and Catch Fire. That's a direct contradiction. If

> I actually don't care too much about getting WebGL out of the main UI thread. I'm doing WebVR work, Halt and Catch Fire. That's a direct contradiction. If you're doing work on WebVR you should absolutely care about WebGL in workers. See: https://www.youtube.com/watch?v=XvoBR9K3ZmE https://www.youtube.com/watch?v=XvoBR9K3ZmE Consider running physics in separate thread, rendering in a thread, and sampling from the VR positional sensor and HMD in the main thread. GC pauses in one thread should not affect other threads.

moron4hire 11y ago
Maybe I'm confused about the documentation here, but it seemed like this was rendering to a back buffer, not directly to the front buffer, that you'd still need to postMessage something back to actually view the results of the rendering. The messaging pipe is not free. Well, I get what you're saying, that you could at least still render a supersampled image and update view over a subset of that image in the main thread. But that's Asynchronous Time Warp, and Chrome already has it (Firefox, however, does not yet have it).
- ndesaulniers 11y ago
  > Maybe I'm confused about the documentation here, but it seemed like this was rendering to a back buffer, not directly to the front buffer In most implementations, WebGL is triple buffered on Windows (since Firefox and Chrome go through ANGLE), or are double buffered. No one ever renders directly to the front buffer. I highly recommend reading chapters 1 and 2 of WebGL Insights edited by P. Cozzi. (shameless plug, I wrote chapter 5).
  - moron4hire 11y ago
    I'm too tired to look it up right now (I'm in DC, check the news), but I believe the WebVR implementations are trying to remove triple-buffering, because entire frames of latency are bad news. I don't want to put words in Brandon Jones' mouth, but I seem to remember him talking about having it implemented in Chrome, which came part-and-parcel with unhinging requestAnimationFrame from the "default" refresh rate of 60hz and using the actual, target display's refresh rate. Mozilla apparently has some hurdles to get over before it's able to do this, so Firefox is lagging in a pure performance standpoint (though it is slightly more stable).

moron4hire 11y ago

Maybe I'm confused about the documentation here, but it seemed like this was rendering to a back buffer, not directly to the front buffer, that you'd still need to postMessage something back to actually view the results of the rendering. The messaging pipe is not free. Well, I get what you're saying, that you could at least still render a supersampled image and update view over a subset of that image in the main thread. But that's Asynchronous Time Warp, and Chrome already has it (Firefox, however, does not yet have it).

ndesaulniers 11y ago
> Maybe I'm confused about the documentation here, but it seemed like this was rendering to a back buffer, not directly to the front buffer In most implementations, WebGL is triple buffered on Windows (since Firefox and Chrome go through ANGLE), or are double buffered. No one ever renders directly to the front buffer. I highly recommend reading chapters 1 and 2 of WebGL Insights edited by P. Cozzi. (shameless plug, I wrote chapter 5).
- moron4hire 11y ago
  I'm too tired to look it up right now (I'm in DC, check the news), but I believe the WebVR implementations are trying to remove triple-buffering, because entire frames of latency are bad news. I don't want to put words in Brandon Jones' mouth, but I seem to remember him talking about having it implemented in Chrome, which came part-and-parcel with unhinging requestAnimationFrame from the "default" refresh rate of 60hz and using the actual, target display's refresh rate. Mozilla apparently has some hurdles to get over before it's able to do this, so Firefox is lagging in a pure performance standpoint (though it is slightly more stable).