2014-05-06 11:04 GMT-04:00 Anne van Kesteren <ann...@annevk.nl>: > On Tue, May 6, 2014 at 3:57 PM, Thomas Zimmermann > <tzimmerm...@mozilla.com> wrote: > > I think Khronos made a bad experience with backwards compatible APIs > > during OpenGL's history. They maintained a compatible API for OpenGL for > > ~15 years until it was huge and crufty. Mode switches are their solution > > to the problem. > > Yes, but Khronos can say that at some point v1 is no longer supported. > Or particular GPU vendors can say that. But this API is for the web, > where we can't and where we've learned repeatedly that mode switches > are terrible in the long run. >
For the record, the only time the Khronos broke compatibility with a new GL API version, was with the release of OpenGL ES 2.0 (on which WebGL 1 is based), which dropped support for OpenGL ES 1.0 API. That's the only ever instance: newer ES versions (like ES 3.0, on which WebGL 2 is based) are strict supersets, and regular non-ES OpenGL versions are always supersets --- all the way from 1992 OpenGL 1.0 to the latest OpenGL 4.4. This is just to provide a data point that OpenGL has a long track record of strictly preserving with long-term API compatibility. The other point I'm reading above is about mode switches. I think you're making a valid point here. I also think that the particulars of WebGL2 still make it a decent trade-off. Indeed, the alternative to doing WebGL2 is to expose the same functionality as a collection of WebGL 1 extensions (1) (In fact, some of that functionality is already exposed (2)). We could take that route. However, that would require figuring out the interactions for all possible subsets of that set of extensions. There would be nontrivial details to sort out in writing the specs, and in writing conformance tests. To get a feel of the complexity of interactions between different OpenGL extensions (3). Just exposing this entire set of extensions at once as "WebGL2" reduces a lot of the complexity of interactions. Some more particulars of WebGL2 may be useful to spell out here to clarify why this is a reasonable thing for us to implement. WebGL2 follows ES 3.0 which loosely follows OpenGL 3.2 from 2009, and most of it is OpenGL 3.0 from 2008. So this API has been well adopted and tested in the real world for five years now. ES 3.0 functionality is universally supported on current desktop hardware, and is the standard for newer mobile hardware too, even in the low end (for example, all Adreno 300 mobile GPUs support it). We have received consistent feedback from game developers that WebGL 2 would make it much easier for them to port their newer rendering paths to the Web. The spec process is already well on its way with other browser vendors on board (Google, Apple) as one can see from public_webgl mailing list archives. Benoit (1) http://www.khronos.org/registry/webgl/extensions/ (2) E.g. http://www.khronos.org/registry/webgl/extensions/WEBGL_draw_buffers/ and http://www.khronos.org/registry/webgl/extensions/ANGLE_instanced_arrays/ (3) Search for the phrase "affects the definition of this extension" in the language of OpenGL extension specs such as http://www.khronos.org/registry/gles/extensions/EXT/EXT_draw_buffers.txt to mention just one extension that's become a WebGL extension and part of WebGL 2. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
