On Wednesday, May 7, 2014 9:20:18 AM UTC-4, Ehsan Akhgari wrote:
> On 2014-05-07, 6:15 AM, Anne van Kesteren wrote:
>
> >> WebGL is already following the OpenGL path. Trying to make it more
> >> "webby" by trying to mush the APIs together isn't doing the web a favor
> >> since the API is already more OpenGL-like, isn't doing developers a favor
> >> since they now have to have this pile of getExtension() code around, and
> >> is definitely not doing us a favor, because we have to support the
> >> explosion of all combo of extensions.
>
> >
>
> > Again, this seems like a false comparison. No need for an explosion of
> > extensions. Furthermore, what you're advocating will give us an
> > enormous API surface area long term, which we'll have to maintain and
> > test, even though most new content will not use it (they'll get the
> > newer classes).
>
> So earlier I suggested feature detecting based on _a_ new WebGL2
> feature, to which Benoit replied that is a bad idea since your code
> would be testing something and assuming unrelated support of other
> features based on that (which _is_ bad practice, but I thought is a goal
> of the all-or-nothing approach of the WebGL2 API.)
>
> So in response, I suggested making individual features feature
> detectible (which is totally doable in your FOO/FROB/BLARG example BTW!)
> to which you replied saying that is a bad idea since all of the features
> are either supported or not (if I understand your response correctly.)
>
>
> I think one possible middle ground would be to define the API as follows:
>
> interface WebGL2RenderingContext : WebGLRenderingContext {
> // new methods go here
> };
>
> partial interface HTMLCanvasElement {
> (CanvasRenderingContext2D or
> WebGLRenderingContext or
> WebGL2RenderingContext) getContext(DOMString id, optional any
> options = null);
> };
Totally with you. That's how the current implementation works.
> And keep the string "webgl" as the name of the context. This way, Web
> content can do the following checks:
>
> if (window.WebGL2RenderingContext) {
> // this browser supports the WebGL2 APIs
> }
>
> var ctx = canvas.getContext("webgl");
>
> if (ctx instanceof WebGL2RenderingContext) {
> // I actually got a WebGL2 context, my hardware also supports it!
> }
Ok, now you lost me for a bit. Why is this better than:
var ctx = canvas.getContext("webgl2");
if (!ctx) {
ctx = canvas.getContext("webgl");
useWebGL1Renderer = true;
}
> This will preserve the all-or-nothing-ness of the WebGL2 feature set, it
> will not require maintaining different code paths depending on which set
> of individual extensions are enabled, is completely forward/backward
> compatible, and at least limits the API surface that we will need to
> support forever.
WebGL 2 is a superset of WebGL 1. So the API surface we need to support
doesn't get any more complicated, except for explicit "is webgl2 in use"
checks. The actual C++ implementation has explicit inheritance even.
Doing getExtension("webgl2") seems weird, and also requires extra
implementation work since we need to create the right kind of OpenGL context
under the hood. Currently we do that when we call getContext. If we had to
wait until getExtension("webgl2"), then we'd need to recreate the context. To
do that, we'd have to either define that you're not allowed to call any context
API functions before calling getExtension("webgl2"), making that the only
"extension" to have that limitation, or we'd need to trigger a context lost and
require all content to wait for a content restored event in order to continue
rendering. This is added complexity both for developers and implementations
for zero benefit.
In the future, there might be a WebGL 3 that's a complete API departure from
WebGL 1/2, which would require a new context name anyway.
WebGL made an explicit decision to do things this way -- the one thing that I
would go back and change is getExtension() returning an extension object,
instead of acting as an enableExtension(). I don't remember *why* we did this,
but I seem to recall some decent arguments for it.
There really isn't a good solution to this problem in general. The Web has
tried multiple things, including the WebGL approach. All of them have a set of
upsides and downsides; there isn't a perfect option.
- Vlad
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
