[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 11:31 AM, Glenn Maynard <email@example.com> wrote:
> On Thu, Dec 1, 2011 at 1:51 PM, Chris Marrin <firstname.lastname@example.org> wrote:
>> 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
> 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:
>> if (ctx.compressedTexSupported("ETC1_RGB8_OES")
>> 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");
> ctx.compressedTexImage2D(..., etc1.RGB8);
> 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.)
This structure, originally suggested by Tim, sounds good to me as
well. Defining different interfaces for different compressed texture
formats' enums will make it easier to support new formats without
interfering with previously defined formats. Explicitly enabling
support for particular compressed texture formats is very much in line
with how other WebGL extensions work. If, hypothetically speaking,
some compressed texture format were added to the core API, that also
seems evolvable; the enum would be added to the WebGLRenderingContext,
and the compressed texture entry points would always support the enum
without enabling an extension.
Chris, I certainly agree with your sentiment that we need to stop
making changes in order to snapshot the next version of the spec.
After considering the pros and cons of adding these entry points to an
extension object or the WebGLRenderingContext, I still think is that
it is worth adding these entry points to the WebGLRenderingContext
now. It seems inevitable that they will be added to the core API at
some point, and defining them on an extension object is problematic
when defining separate extensions for separate compressed texture
Gregg's proposal at
could be used as the starting point for the signatures and semantics
of the entry points, to speed their specification.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: