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

Re: [Public WebGL] texImage2D changed...

On Mon, Aug 9, 2010 at 11:13 AM, <steve@sjbaker.org> wrote:
I loaded up last night's Minefield-for-Windows 32 bit build (20100809 Win
4.0b4pre) - and it crashed on loading my WebGL app (which had been working
just fine 30 seconds earlier on a nightly build from a few days ago!)


In desperation I tried turning *off* the webgl.shader_validator - and
doing that got me a decent error message - which was that this line of
_javascript_ code:

  gl.texImage2D( gl.TEXTURE_2D, 0, image, true ) ;

...has too few parameters.  I can't imagine that the validator would know
or care about that - so probably the validator is crashing for some
unrelated reason.

Anyway - I guess that form of texImage2D got obsoleted somehow.  I looked
at the WebGL spec and some of the working example code to see how we load
images from URL's nowadays...and as a quick test, I tried this:

   gl.texImage2D ( gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA,
                                     gl.UNSIGNED_BYTE, image);

That gets my program running again...but now my textures are all screwed
up.  I'm using PNG and my textures are a mix of RGB's and RGBA's - with
the occasional monochrome PNG tossed in for good measure.  So presumably I
need to set the two format parameters according to what's actually in the
PNG file.

No, you don't have to set those to match the png file. The WebGL spec details that WebGL will convert the image to the format you specify. The new API is far more flexible than the old one.

However, that's a major pain in the butt.  I certainly don't want to have
to write _javascript_ code to read the PNG header (libPNG for _javascript_?!?)
just to find out whether it's RGB, RGBA, Luminance or Luminance/Alpha.  My
art path automagically chooses the most efficient PNG format - so it's
more or less on the whim of the art guys how my textures show up.

This newer form of texImage2D simply isn't very helpful. If we are
extending the traditional OpenGL API to include image loading (which I
think is "A Good Thing" because parsing image files in client-side
_javascript_ is painful) - then we should do it properly and have it set the
format parameters intelligently by examining the incoming image data
rather than having everyone have to write _javascript_ code to do that.

Am I missing something here?  Is there still a way to get WebGL to
auto-detect the format?  This evidently worked before (like, yesterday!) -
so clearly it could be made to work again...I think it should. 


 -- Steve

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: