The crux of the issue here seems to be whether we want WebGL to be more
like OpenGL or more like the web. Each approach carries an impedence
mismatch with a large class of content. So it kind of boils down to whether
we're more trying to lure OpenGL developers to the web or lure web
developers to 3D.
>From what I understand of our goals and strategy, I think it's probably the
former, especially when you through emscripten and asm.js into the mix. But
I'll defer to others on that.
bholley
On Tue, May 6, 2014 at 4:30 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com>wrote:
> On 2014-05-06, 6:41 PM, Jonas Sicking wrote:
>
>> 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.
>>>
>>
>> The main probably that you have is that you haven't designed the API
>> as to allow authors to test if the API is available.
>>
>> If you had, this discussion would be moot.
>>
>> But since you haven't, you're now stuck having to find some other way
>> of detecting if these features are implemented or not.
>>
>
> Yeah, I think this is the core of the issue. Can we just make sure that
> WebGL2 features which are not in WebGL1 are all designed so that they are
> individually feature detectible? And if we do that, would there be any
> other reason why we would want to define a new version of the context
> object?
>
> Cheers,
> Ehsan
>
> _______________________________________________
> 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
