[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 2010-05-20 18:23, Gregg Tavares wrote:


On Thu, May 20, 2010 at 8:53 AM, Chris Marrin <cmarrin@apple.com <mailto:cmarrin@apple.com>> wrote:


On May 19, 2010, at 7:40 PM, Gregg Tavares wrote:

    >
    >
    > ...
    >
    > What I don't get is why the need for these conversions? If you
    load a grayscale image as RGB you'll get the same visual result as
    LUMINANCE. So it seems like the valid reason to do these
    conversions is for memory savings since you can always create RGB
    or RGBA textures that will give you the same visual result.

    I don't see how loading a grayscale as RGB is the same as
    LUMINANCE. The OpenGL texturing engine deals with LUMINANCE
    textures differently from RGB. The problem the information that an
    original image was one channel is lost in the browser
    implementations. Even if not (if the browsers were forced to pass
    along the original image format information) implementations would
    have to have internal format conversion to get the image into the
    right format. So why not expose that to the author?


Can you point out the difference between an RGB image where R == G == B and a LUMINANCE texture? I'm unaware of this difference.


As far as I can tell there is no difference. There's also no difference between an RGBA image were R == G == B and a LUMINANCE_ALPHA texture.

So arguably, the only point in providing the conversions is memory savings. Otherwise there's no functional difference.

Technically that means it doesn't matter what the browser does. It can upload a grayscale image as LUMINANCE or it can upload it as expanded RGB. The WebGL program will not notice the difference. It won't even be able query the difference.

So, the only reason the expose explicit conversions is for memory savings. If that's the only reason then we should be going further. Otherwise we shouldn't be exposing the conversions at all.

As pointed out in a previous mail RGB and LUNIMANCE does differ in some ways and the app can tell the difference. When you just sample the textures they don't differ, but if you try to update a subregion of them using texSubImage2D/copyTexSubImage2D it will fail if you specify the wrong format where 'wrong' depends on the internal format of the texture. You will also get different results if you bind to a FBO and render to them.

For that reason I don't think we should let to browser decide what format to use, it must be specified which internal format is used. If we do let the browser decide we need to block some operations on browser determined formats or we will get incompatibilities.

//Tim

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