So, thinking more about this, here's what I think is the deeper concern
here.
If we make a feature available, we have to expect that people will write
code assuming support for it. We can't honestly believe that all Web
developers write careful feature checks for all the features they depend on.
What is keeping compatibility problems tractable with other Web APIs, in
presence of code that doesn't do careful feature checks, is probably that
support for most Web APIs depends only on the browser and browser version.
That's where WebGL is different: support for WebGL features also depends on
hardware details.
That's why if we just expose different features on the object returned by
getContext("webgl") depending on client hardware details, we will create a
compatibility mess, unlike other Web APIs.
That's why so far the WebGL WG has been very careful with
hardware-dependent feature availability. For example, in WebGL, to rely on
an available extension, you have to first call getExtension to explicitly
enable that extension. That's unlike OpenGL where all available extensions
are readily usable.
Requiring people to write explicitly getContext("webgl2") is similar. It
prevents a situation where in 2016 most application developers have WebGL2
available on their own machine and start writing code depending on it
without really needing it. That matters, because non-WebGL2-capable devices
are going to remain common for a decade.
Benoit
2014-05-06 13:07 GMT-04:00 Boris Zbarsky <bzbar...@mit.edu>:
> On 5/6/14, 12:53 PM, Benoit Jacob wrote:
>
>> Ah, I see the confusion now. So the first reason why what you're
>> suggesting
>> wouldn't work for WebGL is that WebGL extension my add functionality
>> without changing any IDL at all.
>>
>
> Sure, but we're not talking about arbitrary WebGL extensions. We're
> talking about specifically the set of things we want to expose in WebGL2,
> which do include new methods.
>
> In particular, the contract would be that if any of the new methods are
> supported, then FLOAT texture upload is also supported.
>
> The fact that these may be extensions under the hood doesn't seem really
> relevant, as long as the contract is that the support is all-or-nothing.
>
>
> -Boris
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
