[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Compressed texture support in WebGL 1.0.1
On Thu, Dec 1, 2011 at 1:51 PM, Chris Marrin <email@example.com>
I really dislike the idea of one extension per format because it pollutes the extension namespace the worst.
With the way WebGL uses extensions, this is worth solving rather than avoiding.
WebGL (speaking for context; you know this) uses extensions to ensure that users don't use optional features without knowing that they're optional and may not be available on all hardware. If there's hesitation to add new extension strings for fear of polluting the list, this mechanism will be badly limited. As long as the extension names are chosen carefully, I don't think there's a real problem.
If all texture compression extension strings use the same prefix ("WEBGL_texture_compression_", with the exception of prefixed extensions), the extension list is cleanly organized and these extensions sort together.
Similarly, if feature profile extensions are ever explored, using extension strings like "WEBGL_profile_mobile_2012" and "WEBGL_profile_desktop_2013" would keep the extensions in a clear namespace.
Because of this, I tend to prefer a separate extension string for each compression format. It ensures you have to opt into each separate optional feature explicitly, which is a good thing.
when it comes time to move it into the core, you simply add the 3 functions from the extensions and are left with:
ctx.compressedTexImage2D(..., ctx.ETC1_RGB8_OES, ...);
which is the same technique, just without the getExtension call. That seems much cleaner to me.
I don't like this, because it doesn't use the optional feature opt-in that extensions provide.
I think that optional features should *always* continue to require a getExtension call to enable them. Even if the compressedTexImage2D call is rolled into the core eventually, the individual compression formats should still be extensions. A feature should only be enabled by default, with no getExtension call, if the core requires it on all hardware.
var etc1 = ctx.getExtension("WEBGL_texture_compression_etc1");
That seems simple and clean to me.
(Note that there doesn't need to be a separate extension *spec* for each compression format. A single "WEBGL_texture_compression" spec could define several extension strings for different compression formats. The 1:1 mapping between specs and extension strings predates the way WebGL uses extensions; there's no need to retain it, as long as it's easy to find the spec for a particular extension string.)