[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 <firstname.lastname@example.org> wrote:
> On Wed, May 19, 2010 at 10:13 AM, Chris Marrin <email@example.com> wrote:
>> On May 18, 2010, at 2:50 PM, Cedric Vivier wrote:
>> > On Wed, May 19, 2010 at 05:36, Chris Marrin <firstname.lastname@example.org> 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.
In desktop GL, the packed pixel types can only be used with certain
formats. For example, a type of GL_UNSIGNED_SHORT_5_6_5 must be used
with a format of GL_RGB or GL_INVALID_OPERATION is generated. See
> It really seems all this conversion belongs outside of texImage2D. add
> ArrayBuffer ctx.convertTo(img, format, ....) or something like that.
>> You are currently subscribe to email@example.com.
>> To unsubscribe, send an email to firstname.lastname@example.org with
>> the following command in the body of your email:
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: