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

Re: [Public WebGL] Move flipY and asPremultipliedAlpha parameters out of DOM helpers



On Fri, May 21, 2010 at 22:46, Gregg Tavares <gman@google.com> wrote:
> Adding support for LUMINANCE will save memory on about 1 out of 1000 apps.

Do you have stats about this ? Are normal maps, bump maps, light maps,
alpha masks so rarely used really ?
Wouldn't this block or complicates some very legitimate usages and/or
porting from GL ?
Also conversion from RGBA to RGB is a straightforward choice that a
lot of textures can use, providing 25% savings 'for free'.

I think there is a lot of confusion around LUMINANCE because of its
name that is an artifact of the pre-shaders world... in ES 2.0 and
modern GL, LUMINANCE does not mean "grayscale", it just means
one-component texture, with the first R component replicated to G and
B components, likely for visual compatibility with the older meaning
of LUMINANCE.
In modern GL we have GL_R instead of GL_LUMINANCE to express that
better, and GL in 3.3/4.0 contexts does not even do the replication of
the R component to G and B anymore, since shaders can do it as
efficiently (that's less work for GL to do when the shaders do not
need G and B components).

Afaik LUMINANCE and grayscale can be used in 3 different ways :

1) automatic selection of LUMINANCE can be done ONLY when the DOM
image is itself a one-component image (e.g PNG type 1 aka grayscale)

2) developer specifically wants to store in LUMINANCE (4x reduction in
memory), the image likely is a mask/map (precomputed elsewhere) or
already a grayscale image, which means R is same value of other
components... even if the DOM image is in a 3 or 4 component format
originally.

Afaik the case where there is debate is :

3) developer wants a grayscale _visually_ from an _arbitrary_ DOM
image (e.g non-grayscale RGB).

I would argue the texture can be loaded as usual and the grayscaling
efficiently and dynamically done in the shaders with the formula he
prefers (e.g grayscale or desaturate, _dynamic fade to gray
animation_, ...).
If we consider _static_ grayscale use-case common enough to deserve an
option to convert a RGB image to grayscale on the CPU with "the most
common formula", in order to save memory easily for this specific
usage, then we could add a DOM_GRAYSCALE option, e.g:

texImage2D(gl.TEXTURE_2D, 0, gl.LUMINANCE, img, gl.DOM_GRAYSCALE |
gl.DOM_FLIP_Y)

It is then explicit when the developer wants a static grayscale
visually, it does not break what modern GL developers would be
expecting of LUMINANCE alone, and last but not least it makes clear to
web developers that LUMINANCE does not necessarily mean grayscale in a
shader-based world ; which will help when WebGL updates to a newer
revision of ES using GL_R instead of LUMINANCE.


> Adding support for 16 bit formats will save memory on any app that chooses
> to use it. Lots of apps will choose to use it, especially given there is no
> other texture compression available.

Changing the number of components related to which components are
necessary for the image does not alter quality, changing the number of
bits per pixel on the other hand does alter quality.
That's not a choice that every app will be comfortable with
(especially on desktop).

internalformat and type are not exclusive to each other, I agree that
we should support type, for the reasons you cited but also for having
the most similar signature to GL, leaving out from the DOM helpers
only the parameters which can be inferred from elsewhere (ie. width
height format border...).


Regards,
-----------------------------------------------------------
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: