[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Removal of glTexImage3D entry point?
I just ran into another, maybe deeper problem with the removal of texImage3D: if my understanding of the spec is correct, it removes functionality.
I have an OpenGL ES 3 application that uses a 3D texture with ALPHA format. Is there any way to get that with texStorage3D? texStorage3D only accepts sized internalformats (indeed, it does not take a type parameter, so an unsized internalformat would remain ambiguous). But there is no sized internalformat value for any ALPHA format in the spec: ALPHA8, ALPHA16F and ALPHA32F are not listed among valid sized internalformats anywhere in the ES3 spec (e.g. Table 3.2). Moreover, at least ALPHA8 is explicitly described as a dummy effective internalformat not corresponding to any GLenum constant, in the ES3 spec (Table 3.2).
The same issue also with LUMINANCE_ALPHA.
I understand that ALPHA and LUMINANCE_ALPHA textures are deprecated, but does there exist any reasonably simple, automatic porting path for ES3 applications relying on them? Something that would be reasonable to implement in a place like Emscripten's OpenGL-to-WebGL layer?
You make good points about not arbitrarily subsetting OpenGL ES 3. The thought in the WebGL working group at the time was something along the lines of: it would have been far better if mutable texture allocation functions had not been present in the first place (far simpler texture validation logic, etc.); and since 3D textures were being newly introduced, there was an opportunity to avoid widespread usage of an undesirable entry point. (We considered dropping TexImage2D in WebGL 2, but that would have broken basically all applications.)
You're correct that it isn't simple to emulate TexImage3D on top of TexStorage3D and TexSubImage3D. However, one point is that it should not be difficult to change existing OpenGL ES 3.0 code to use TexStorage3D instead of TexImage3D. For the long term, it still might be a good idea to push developers in the direction of using the immutable allocation functions, and not providing TexImage3D in Emscripten's emulation layer.
More opinions please?