[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Public WebGL] backwards compatibility handling
It is possible that successive versions of WebGL wish to remove functionality that was contained previously in order to get rid of cruft. To some extent this is already the case with WebGL 2 as the example below illustrates:
The texImage family of calls in ES 2 (and WebGL 1) accept unsized internalformat parameters such as RGB, RGBA, LUMINANCE_ALPHA, LUMINANCE and ALPHA.
In ES 3 (and WebGL 2) a host of new sized formats is introduced, for example: R8, R8_SNORM, R16F, R32F etc.
If you enable OES_texture_float in WebGL 1 this call becomes valid:
texImage2D(TEXTURE_2D, 0, RGBA, x, y, 0, RGBA, FLOAT)
However ES 3 has floating point texturing support built in (and so OES_texture_float will not be offered as an extension) you will also have to change the call to account for that only sized internalformats are valid to pass for this type:
texImage2D(TEXTURE_2D, 0, RGBA32F, x, y, 0, RGBA, FLOAT)
At this time most of the backwards compatibility breaking changes are related to extensions. However future revisions of the standard might also have core incompatibilities.
The way this has been handled in OpenGL is by defaulting to something called a "compatibility profile" which contained everything from previous revisions of the standard in addition to the new stuff. This is undesirable for obvious reasons.
However the problem this solves should not be ignored, it's how people can deploy applications written against different versions of the standard in transitionary periods where support for a new standard isn't as widespread and so older profiles need to be supported as well. Obviously it would be bad if you had to maintain two separate implementations, and even writing cleanly separable code can be a challenge sometimes.
In a nutshell, it makes it easier (for the right kind of programmer) to migrate to newer profiles. Unfortunately it also makes it easier (for the wrong kind of programmer) to produce messy dysfunctional GL code, which has lead to various initiatives/libraries attempting to provide clean core profiles. Fortunately WebGL doesn't have this problem (yet).
I feel it's important to have a discussion about how this should be handled in WebGL, and I see 3 alternatives (examples)
- Do not handle it, features in WebGL are liberally removed in backwards compatibility breaking ways. This will make it a bit harder to adopt newer WebGL profiles, but it will prevent mixed spagetti code and it probably makes life easier for vendors.
- Introduce the concept of a compatibility profile which you default to (i.e. gl.getContext('webgl2') -> webgl2 compatibility profile, gl.getContext('webgl2-core') -> webgl2 core profile. This comes with all the drawbacks of the traditional OpenGL solution to the problem.
- Introduce the concept of a compatibility profile, but default to core (i.e. gl.getContext('webgl2') -> webgl2 core, gl.getContext('webgl2-compatibility') -> webgl2 compatibility profile.