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

Re: [Public WebGL] Generic compression formats (and a texImage2D API issue)



On Thu, May 13, 2010 at 01:41, Chris Marrin <cmarrin@apple.com> wrote:
> I've thought about this as well. We could support a compressed texture format without actually defining any specific formats. Doing it as a hint, the implementation would be free to ignore it and store the texture uncompressed, or use whatever texture compression format is available in the driver. This avoids the licensing issues associated with texture compression. If your implementation has rights to a compressor that is used in your graphics driver, then you can implement it.
>
> My only concern about this is that different texture compression formats have different rendering characteristics. Some have more green resolution than blue, others have more luminance resouiton that chrominance, etc. This could cause inconsistencies. But as long as the author understands that using compression is always an approximation, I don't think this problem is too significant.

Yes, that's exactly what generic formats are about :)
This is imho much more web-ish and appropriate to WebGL than expecting
web developers to generate as many textures as there is formats to
support - an issue similar to the <video> codecs situation.


> But I also think this should go on the list for post 1.0.

Yeah certainly makes sense.

However, I still believe we should add internalFormat to texImage2D
DOM helpers [1] rather sooner than later, more arguments below as
answer to Gregg's proposed workaround :


On Wed, May 12, 2010 at 00:38, Gregg Tavares <gman@google.com> wrote:
> We can add a new function to the extension
>
> var compressedTextures = ctx.getExtension("compressed-textures");
> var t = ctx.createTexture();
> ctx.bindTexture(ctx.TEXTURE_2D, t);
> compressedTextures.texImage2D(params...needed...to...support...compressed...textures);

The spec says an extension object does not necessarily contains
functions, getting an extension object possibly just enables an
extension's features and contain no member or just new enums (target
points, formats, ...) - just like many GL extensions which do not
introduce new functions.
Unnecessarily diverging from GL's extension mechanism does not make
sense imho and will just add a bunch of unnecessary and confusing
stubs/signatures to extension objects, making harder extension
documentation, testing, and porting (from native GL or ES).

The "standard" texImage2D signature already has all parameters needed
since it has the same signature as GL's, the issue is only with DOM
helpers [1] lacking the internalFormat parameter, which - in contrast
to other parameters - is the only one that cannot be inferred from the
DOM object (e.g width/height...) since this is a developer choice.
I understand why internalFormat may not have been considered in the
helper signatures initially since the ES spec says that internalFormat
must be equal to format it could be seen as superfluous. However I do
not believe this is a future-proof extension-friendly decision since
any ES extension (or future ES revision) can specify another behavior,
especially in the light of GL<->ES convergence and hinting-only
format-agnostic ARB_texture_compression-like solutions (which could be
available on WebGL, as desktop-specific extension at least).

Finally, as discussed in another thread, there is few reasons for
WebGL not to propose - at some point - the facility to extract only
alpha channel or luminance from any DOM element in a much simpler and
efficient way (therefore friendlier to ES devices at the same time)
than having to load an image or video frame first into a offscreen
Canvas then extract/manipulate every pixel's components individually
in JavaScript.


Adding an optional internalFormat parameter to texImage2D helpers makes WebGL :

- avoid the need to redeclare the 4 DOM helpers with one additional
parameter in every format-related extension, diverging from
traditional GL-isms and forcing web developers to refactor the way
those texImage2D calls instead of just changing one parameter value
(as in GL).

- extensions aside, avoid doubling the number of texImage2D overloads
(5 of them already) if/when a future ES revision allows internalFormat
not equal to format [native ES will not need to introduce a new
function for that since internatFormat is already on the only only
texImage2D signature even if it is "useless" right now].

- enable "shimming" discussed alpha/luminance from DOM element use
case until WebGL (or a WebGL extension) supports it natively; here
again simplifying porting/prototyping from GL.


Regards,

[1] : texImage2D with a HTMLImageElement, HTMLCanvasElement or
HTMLVideoElement as data argument.

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