[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 2:01 AM, Tim Johansson <timj@opera.com> wrote:
On 2010-05-20 19:00, Gregg Tavares wrote:

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

   On May 20, 2010, at 9:23 AM, 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.

   I feel very old. There was a time that LUMINANCE textures behaved
   differently that RGB in the face of the various texturing modes.
   Those are all gone in a shader based world. So you're right, there
   is no 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

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

   Right, but I don't think we can underestimate the significance of
   that memory savings, especially in embedded devices. It can easily
   mean the difference between content working and exhausting memory.
   So I reiterate my opinion that we should add internalformat to
   texImage2D in the 4 cases that take HTML objects.

And if the reason for doing this is memory savings then we need to add support for 565 5551 and 4444.  All of which are supported by OpenGL ES 2.0 (and therefore WebGL)

That means just adding internalFormat to texImage2D is not enough.

Either we are trying to do this for memory savings or we aren't.

Adding only internal format will save memory in some cases and adding support for 16 bit format will save more memory in some cases. I don't really see why it has to be all or nothing, that 16 bit format can save more memory does not change the fact that exposing internal format will save some memory in some cases. If one is easier to add than the other, why not just add the easiest one and save a little bit of memory?

Adding support for LUMINANCE will save memory on about 1 out of 1000 apps.

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.

So why waste the effort for supporting some format that almost no one will use vs one that many will use?

I don't really think it will be easy to add guessing of internal format based on the input image in a reliable way though, so I think we need to be very careful about how we expose the internal format if we do so.


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: