2014-05-06 12:11 GMT-04:00 Boris Zbarsky <bzbar...@mit.edu>: > On 5/6/14, 12:03 PM, Benoit Jacob wrote: > >> Indeed, the alternative to doing WebGL2 >> is to expose the same functionality as a collection of WebGL 1 extensions >> > > I think Anne's question, if I understood it right, is why this requires a > new context ID. > > I assume the argument is that if you ask for the WebGL2 context id and get > something back that guarantees that all the new methods are implemented. > But one could do something similar via implementations simply guaranteeing > that if you ask for the WebGL context ID and get back an object and it has > any of the new methods on it, then they're all present and work. > > Are there other reasons there's a separate context id for WebGL2? >
To what extent does what I wrote in my previous email, regarding interactions between different extensions, answer your question? With the example approach you suggested above, one would have to specify extensions separately and for each of them, their possible interactions with other extensions. Moreover, most of the effort spent doing that would be of little use in practice as current desktop hardware / newer mobile hardware supports all of that functionality. And realistically, the primary target audience there is games, and games already have their code paths written for ES2 and/or for ES3 i.e. they already expect the mode switch. Benoit _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
