Chrome crashing...

My current WebGL-App does run fine under Firefox. Currently I’m trying to get it to run on Chrome/Webkit. For some strange reason it’s just crashing the JS-Tread: … quest.html

I have absolute no idea what’s causing this. Chrome seems to have some kind of build in JS-Debugger which could be useful here. The problem is: Either it does not work or I’m to stupid to use it. Breakpoints do not have any effect? Could anyone help me trying to find the line causing the problem? (The sourcecode is generated by GoogleWebToolkit with style “PRETTY”)

Actually there is NO demo I get to run with the current Chrome build I got here. In all demos I tried I got an error that function getShaderi does not exist. That’s why I’m executing the following compatibility code:

if (!gl.getShaderi) {
	gl.getShaderi = gl.getShaderParameter;
if (!gl.getProgrami) {
	gl.getProgrami = gl.getProgramParameter;

Yeah, bit me too :frowning:

Is Mozilla also adapting this API?

Is Mozilla also adapting this API?

I don’t know why Chrome has now getShaderParameter and getProgramParameter. Thats out of OpenGL ES 2.0 specification. However, Firefox has both methods and it seems they are identical to getShaderi respectively getProgrami.

But, that does not explain why Chrome is crashing. I think I will have to insert log messages everywhere in my code to get a hint where this crash happens. The problem is I’m developing on Linux and Chrome with WebGL does only run on Windows for me. I have to reboot every time I want to change something in the code. That makes debugging using log messages really hard. A working Chrome debugger would be much easier…

Smash head on keyboard to continue…I was using the wrong Chrome version, that was also the reason why nothing else worked. When using the DevChannel-Version it work’s fine.

Re: geti -> getParameter, it seems to be a recent rename

I think Firefox is going there as well (if isn’t there already, IIRC Firefox was using the getParameter stuff to begin with, then added the geti aliases at some point.) But yeah, joys of in-development APIs.

It looks like it was WebKit checkin #51348 that made the change – the message says:

    Change get... calls to latest spec
    Removed old versions of get calls on WebGLRenderingContext and
    added new ones per spec returning "any". New code simplifies
    GraphicsContext3D and fixes previously unimplemented routines.
    Added custom JS and V8 bindings. Added exhaustive test case
    exercising all new code paths. Updated preexisting test cases for
    new APIs. Fixed preexisting bugs in WebKit's and Chrome's WebGL
    Ran WebGL layout tests in WebKit (clean) and Chrome (couple of
    preexisting known failures) and manual WebGL tests in both

It’s a huge change, but the relevant bits (I think) are the ones in WebCore/html/canvas/WebGLRenderingContext.cpp and its associated header, and as far as I can make out from the diffs, they are:

[li]A few bits of improved error handling[/:m:dhgt0vrt][/li][li]getBoolean, getBooleanv, getFloat, getFloatv, getInteger, getIntegerv merged to getParameter[/:m:dhgt0vrt][/li][li]getBufferParameteri, getBufferParameteriv merged to getBufferParameter[/:m:dhgt0vrt][/li][li]getFramebufferAttachmentParameteri, getFramebufferAttachmentParameteriv merged to getFramebufferAttachmentParameter[/:m:dhgt0vrt][/li][li]getProgrami, getProgramiv merged to getProgramParameter[/:m:dhgt0vrt][/li][li]getRenderbufferParameteri, getRenderbufferParameteriv merged to getRenderbufferParameter[/:m:dhgt0vrt][/li][li]getShaderi, getShaderiv merged to getShaderParameter[/:m:dhgt0vrt][/li][li]getTexParameterf, getTexParameterfv, getTexParameteri, getTexParameteriv merged to getTexParameter[/:m:dhgt0vrt][/li][li]getUniformf, getUniformfv, getUniformi, getUniformiv merged to getUniform[/:m:dhgt0vrt][/li][li]getVertexAttribf, getVertexAttribfv, getVertexAttribi, getVertexAttribiv merged to getVertexAttrib[/:m:dhgt0vrt][/ul][/li]
I think I prefer the new names; they seem more appropriate for a dynamic language like JavaScript, while the older ones were much better designed for the statically-typed C/C++. Of course, this does mean that WebGL is becoming less and less of just a set of JavaScript bindings for OpenGL ES 2.0, but that may be a good thing.

Does anyone (Ilmari?) know where the equivalent file to WebGLRenderingContext.cpp, defining the public interface for the WebGL context, exists in the Firefox source tree? I did have a link to an IDL file that seemed to perform the same function, but I’ve lost it. It’d be great if I could put together a compatibility patch to put at the start of my lessons (and for other people to use) that would allow us to use the new API while retaining Firefox compatibility, but that’ll be tricky if the untyped get… methods don’t all exist there. (Of course, I could just try them and see if they work, but it would be nice to see the source :slight_smile:

IDL: … GL.idl#776
Implementation: … L.cpp#1268

Thanks, Ilmari – that’s the one!

So, from the diffs there it looks like Mark Steele checked an equivalent change in to Firefox on 18 November, but was kind enough to leave the --i versions there (flagged “// XXX remove”) for the time being.

Given that both browsers are moving toward the new system, Firefox supports both the old and the new names, and WebKit supports only the new ones, I guess it’s time to change our demos.

Looking forward to the draft spec…