Random WebGL related gunk

There's a few things I've come across in the last few days that I feel are worth pointing out to the WebGL community:

• Newer builds of Firefox have started validating the textures passed to generateMipmaps according to the OpenGL ES 2.0 spec. This means that attempting to generate mipmaps with non-power-of-two textures will start failing on you very soon! Please update you code/resources accordingly. (This already bit me with my Quake demos, which have now been tweaked accordingly.)
• WebGL___Array types are going, going, gone! Newer browser builds don't even have them defined, so make sure you are using the appropriate analogs from the Typed Arrays. Again, my demos have been updated to account for this.
• In an odd twist, whereas Firefox has been speeding up lately apparently Chrome is cracking down on crazy fast loops now. With the latest dev releases (7.xx) I've noticed that my Quake 3 demo is basically locked at 30fps, regardless of whether or not you check "Cap FPS". Curiously, this does not seem to be the case for my Quake 2 demo, which means that Chrome is actually limiting the internal message pump. Granted, it's a very stable 30fps, and I'd rather have a lower but stable framerate than a high but erratic one, so I'm not complaining. It did strike me as an interesting change, though. A bit of background on this one: For the Quake 3 demo in order to get the best framerates possible I used a hack picked up from Vladimir Vukicevic that continually posts messages to the page as a signal to draw (demo), which attempts to avoid some of the resolution limitations of setTimeout/Interval. This apparently causes severe performance issues if allowed to run rampant, however (as commenters on this site have pointed out) and so it's possible that this apparent capping may be Google trying to prevent abuse of the system. (Which is probably a good thing!) I'd love to know a bit more about the actual changes that took place in this regard, but in the end it appears that the timer-based method is the better way to go.
• Finally, in a bit of news that has nothing to do with WebGL whatsoever, I find this to be supremely amusing. Chrome envy, perhaps? :) It's especially funny in light of some Google-bashing that Microsoft did a few months back about how a single address/search bar was a bad thing for users privacy.

Spring (er.. late Summer?) Cleaning

As a heads up, some of my older demos (well, basically everything but the Quake 3 demo) are probably broken on newer browser builds at this point due to changes in the WebGL's API. (Hey, that's what you get for developing against experimental libraries!) Over the next couple of days I'm going to go back and fix them up (may even try to optimize the code a bit), so hopefully everything should be working again soon.

Until then, sorry for any broken code you may stumble across!

Update: So I've got all of the demos to stop throwing errors, but the Spore and Hellknight demo's aren't showing anything, even though they appear to load correctly. I'll continue looking into it, but in the meantime at least the Quake 2 and 3 demo's are running fine.

Obsolete texImage2D... Wha?

I've seen a couple of people around the web mention that with newer versions of WebKit they have begun getting the following warning in their console when running WebGL apps:

Calling obsolete texImage2D(GLenum target, GLint level, HTMLImageElement image)

Calling obsolete texImage2D(GLenum target, GLint level, HTMLImageElement image, GLboolean flipY, GLboolean premultiplyAlpha)



Things still work this way but obviously having the browser barf out a bunch of warnings is less than desirable. Fortunately a bright guy at http://darkhorse2.0spec.com/ (site is in Japanese) did some digging through Webkit's code and found the "right" definitions, which he lists. For me, I was able to get the errors to go away by changing my code from:


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

to:

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


And yes, that works with Minefield too. (Well, technically Firefox 4 beta 1) Of course, this probably only works for me because I happen to know that all the images I'm loading are 32bit PNG's. I imagine that telling it the image is RGBA if you were using a JPEG may not work so well (I'll have to try that sometime soon), so your mileage may vary.