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

Re: [Public WebGL] Adding internalformat param to all texImage2d variants

On Wed, May 19, 2010 at 10:36 AM, Gregg Tavares <gman@google.com> wrote:
> On Wed, May 19, 2010 at 10:13 AM, Chris Marrin <cmarrin@apple.com> wrote:
>> On May 18, 2010, at 2:50 PM, Cedric Vivier wrote:
>> > On Wed, May 19, 2010 at 05:36, Chris Marrin <cmarrin@apple.com> wrote:
>> >> NONE or NO_CONVERSION would not literally perform no conversion on the
>> >> input image. It would rather make a texture that matches the original image
>> >> format. Since WebKit/Chrome and Firefox both store images internally in RGBA
>> >> (converting images from 1 or 2 channel formats if needed), specifying
>> >> NO_CONVERSION of a 1 channel image will actually have to convert it back
>> >> from RGBA to 1 channel. Of course that's an implementation detail and we
>> >> could always store the original format for avoid that double conversion. But
>> >> I can't see doing that in WebKit in the short term anyway...
>> >
>> > Yes indeed, potential interim conversions are implementation detail
>> > but the result for end user/developer is identical to no conversion...
>> > and could be no conversion at all in implementations that do such
>> > image loading optimizations.
>> >
>> >
>> >> But these function already diverge. They are a bridge between HTML and
>> >> WebGL. They also support y flipping and alpha premultiplying, which are
>> >> >divergent. We need to make them useful to the HTML author, not matching
>> >> OpenGL.
>> >
>> > Yeah but coming from native ES or GL, you could think of the
>> > HTMLImageElement as an "unsigned char*" that has been populated
>> > through libpng or similar. With the a GL-like signature of the helper,
>> > porting is trivial to do because the order of the required parameters
>> > is the same : native code calling texImage2D(...RGB ...  RGB ...
>> > &bytes_from_a_png_loaded_as_rgb) can be directly ported to
>> > texImage2D(...RGB, png_img_element).
>> >
>> > If we add a completely 'alien' convertTo parameter this completely
>> > changes that nice characteristic, this is what I meant by diverging
>> > here.
>> I'm not sure how it's any more alien than flipy and premultipliedAlpha. We
>> might as well argue that naming these functions texImage2D is inappropriate.
>> Perhaps it would be better to have conversion functions that take in one of
>> the image element types and the convertTo, flipy and premultipliedAlpha
>> params and return a filled in ArrayBuffer. I don't particularly like that
>> idea because it would not allow optimizations that might be possible on some
>> platforms, such as directly writing the image to GPU memory using some
>> non-OpenGL mechanism.
> Personally I think this is the better solution.
> We're trying to add all kinds of conversion stuff to texImage2D that may or
> may not make sense.
> How do the types UNSIGNED_SHORT_5_6_5, UNSIGNED_SHORT_4_4_4_4 and
> UNSIGNED_SHORT_5_5_5_1 fit into these conversions? For example one of the
> arguments for supporting conversion to LUMINANCE and ALPHA formats was space
> savings but if that's the argument for supporting conversions then it
> applies to these types as well.
> It really seems all this conversion belongs outside of texImage2D.  add
> ArrayBuffer ctx.convertTo(img, format, ....) or something like that.

I realized last night that this proposed API structure would break the
ability to display images from different domains. It is not allowed to
fetch the bits of images from other domains (cf. the Canvas tag's
origin-clean policy). This means that this API could not work for
images except for those coming from the app's domain, preventing
writing something like a Flickr or Picasa picture viewer in WebGL.


>> -----
>> ~Chris
>> cmarrin@apple.com
>> -----------------------------------------------------------
>> 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:

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: