[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WEBGL_debug_shader_precision extension proposal

On Wed, Nov 12, 2014 at 11:09 AM, Rob Manson <roBman@buildar.com> wrote:
Our first idea was simply to use RGBA/UNSIGNED_SHORT_4_4_4_4 but the initial feedback we got (which made good sense to us) was that a 3 channel data structure like RGB/UNSIGNED_BYTE would save a number of steps in the conversion/unpacking process and would therefore be more efficient.
Sure it's kind of a hassle, but that's kind of the point. I'm making.

We created some tests and ran them across various browsers and during that process also realised that we could get better performance and channel usage by using RGB/UNSIGNED_SHORT_5_6_5 - already a unit16 array and only 3 channels instead of 4.
Actually you could get even better performance out of UNSIGNED_BYTE RGBA, because that's the most heavily optimized format there is, closely followed by FLOAT RGBA.

As far as I'm aware using LUMINANCE_ALPHA/UNSIGNED_BYTE is not as effective as the LUMINANCE_ALPHA is internally converted to an RGBA with the luminance spread across the R, G and B channels. But please correct me if this is not right?
We're talking about fairly negible per-fragment costs in the range of a few percent, if it's even measurable at all given the other timing noise that permeates rendering.
Our primary goal here was simply to find a pragmatic approach that could easily be developed against WebGL 1.x right now - so people could start using Depth Camera Streams via WebGL in the "very near future".
That's good, but a non-extension imo isn't the way.
Then in WebGL 2.x we could just move to using RED_INTEGER so we would then move back to using just standard WebGL with no extension. But waiting for only this option seemed like a long delay when a feasible stop-gap approach seemed available.
So you basically admit that the extension is entirely superfluous to begin with.
If there are other options that could help us meet our primary goal then we'd definitely like to hear about it.
You could achieve the same, not doing an extension at all, because it isn't an extension to begin with.
Yet it does seem to me that the WEBGL_texture_from_depth_video extension does define a very minimal "novel behavior of a piece of software". At the moment there is no way to upload a <video> frame that includes a depth data track. This extension enables that - which makes this novel.
It doesn't. That's what you make the user interprete it as. Like I say, what you've written isn't an extension. It's a user-tutorial on how to interprete some piece of data that happens to fit into the bit-depth you're targeting.

Florian, it sounds like you're saying that our only option is that users/devs really have to wait for WebGL 2.x to access Depth Camera Tracks - am I understanding that correctly?
That's not what I'm saying. I'm saying that this can be specified entirely without an extension, quite easily, in a fashion that will not require any behavioral change whatsoever, neither now, nor in the future.

This is incredibly easy to do, too, it simply goes like this:

"A depth video stream surface is a 16-bit per pixel, one channel pixel surface. It can be uploaded to any matching WebGL internal format."

End of story, bam, you've just specified it, completely, without resorting to any hacks. Only thing left is, you should give a user a way to discover what the depth means, but that's out of scope of an extension anyway, and would best fit into your media depth stream specification, like I said, from the beginning.