[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Removal of glTexImage3D entry point?

I agree (disclaimer, my main use of WebGL is through emscripten).
WebGL should continue to map to a respective OpenGLES version as
closely as possible, unless a feature doesn't make technical sense in
a browser environment (like mapping buffers). If providing a 'cleaned
up' API is one of WebGL's goals, then at least an 'mandatory
extension' should exist which implements the missing functions. But as
long as it only about removing one or two functions for aesthetical
reasons my vote would be to keep the function(s) in the core API.

The subtle differences between OpenGLES and OpenGL are confusing
enough already (and with modern mobile GPUs mostly obsolete I think).


On Tue, Oct 14, 2014 at 9:39 AM, Jukka Jylänki <jujjyl@gmail.com> wrote:
> Hi,
> in the current form, WebGL 2 spec is planning to remove a GLES3 entry point
> it finds to be of "bad form" and use in modern code should be avoided. See
> https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and
> https://github.com/KhronosGroup/WebGL/issues/542 .
> While one can agree that calling glTexStorage3D is of more modern form than
> calling glTexImage3D, I don't agree that it is correct that WebGL 2 should
> start deprecating/erasing API functionality on its own. Especially when
> reading the comments in the issue tracker, the rationale seems to not be
> technical, but only for cleaning and peace of mind purposes. However, these
> kind of changes would break existing GLES3 code that is compiled over to the
> web via Emscripten. Therefore I would recommend that WebGL 2 did not
> arbitrate API cleanups like this, unless the emulation path is a trivial one
> that can be documented in the spec itself. What do you think?
>    Jukka

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl