[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float
It's important to realize that it's only Mozilla who explicitly exposes the extension. At least Chrome (and I believe others) implicitly support the extension, otherwise they cannot support rendering into floating-point FBs.
This is the text from OES_texture_float:
"Implementations supporting float rendering via this extension will implicitly enable the WEBGL_color_buffer_float extension and follow its requirements."
Technically speaking, a spec-compliant implementation cannot expose OES_texture_float, allow render-to-RGBA32F, and not support the WEBGL_color_buffer_float extension. That is, Chrome (for instance) already implicitly claims support for all the restrictions of WEBGL_color_buffer_float if they support OES_texture_float and allow render-to-RGBA32F.
As the spec stands today, Chrome is either out-of-spec in its implicit support of WEBGL_color_buffer_float as invoked by OES_texture_float, or WEBGL_color_buffer_float can be exposed today with no technical issues.
To be clear, as the specs stand today, WebGL implementations may either:
* Allow render-to-float32 when WEBGL_color_buffer_float is explicitly activated
* Allow render-to-float32 when WEBGL_color_buffer_float is implicitly activated by OES_texture_float
* Not allow render-to-float32.
That is spec-as-written today.
WEBGL_color_buffer_float is alive and well, but many implementations are not explicitly claiming support for it. If we reject these extensions, by spec, we'll need to stop allowing render-to-float, or get new extensions.
I posit that we don't actually need new extensions, unless there's a technical reason that puts us all out-of-spec in our support for WEBGL_color_buffer_float, whether explicit or implicit. If there is a technical reason for this, we should rewrite the extension(s) until it's technically and spec-wise feasible to support render-to-float.