[Public WebGL] WEBGL_debug_shader_precision extension proposal

Florian Bösch [email protected]
Wed Nov 12 02:32:18 PST 2014


On Wed, Nov 12, 2014 at 11:09 AM, Rob Manson <[email protected]> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20141112/e06587f5/attachment.html>


More information about the public_webgl mailing list