[Public WebGL] EXT_shader_texture_lod in WebGL2?

Florian Bösch [email protected]
Mon Jan 23 09:36:10 PST 2017

As I've said, I'm not at all for exposing legacy functionality to WebGL2. I
think it's a mistake when OpenGL did it, and I think it would be a mistake
if WebGL started doing it. I referred to the general sentiment of taking
care of WebGL1, even now, especially now, that WebGL2 comes along. Because
not doing so sabotages both WebGL1 and WebGL2.

On Mon, Jan 23, 2017 at 6:18 PM, Zhenyao Mo <[email protected]> wrote:

> It's not abandoning WebGL1 and we understand the importance of WebGL1 to
> developers.
> EXT_shader_texture_lod is an extension that's not even exposed in ES3.
> In theory we can expose all ES3 functionalities to WebGL1 through
> emulation etc, and one can always argue the benefit of exposing this and
> that. I just don't see that as a good way of spending our limited
> engineering resources.
> On Sat, Jan 21, 2017 at 1:17 AM, Florian Bösch <[email protected]> wrote:
>> Writing multiple renderpaths for multiple versions, that take full
>> advantage of the capabilities of each version is very time-consuming and
>> difficult.
>> The easiest way to for developers to take full advantage of WebGL2 for
>> the time being, would be to be able to "polyfill" features they'd like to
>> use into WebGL1 that are found in WebGL2.
>> By abandoning WebGL1, with a very fragmentary capability coverage to
>> WebGL2, you're ensuring that WebGL2 adoption will be much slower than we
>> all wish. That's because there's no easy way to "polyfill" the enticing
>> features of WebGL2 into WebGL1. Although I don't think this should prompt a
>> mass backporting effort, I do think this warrants continued effort to
>> improve the existing WebGL1 capabilities across all UAs and maybe introduce
>> more WebGL1 extensions for particularly sore spots (like 3D textures).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170123/9a639018/attachment.html>

More information about the public_webgl mailing list