The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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:

Re: Chrome crashing...

Re: Chrome crashing...

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...

Re: Chrome crashing...

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

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

Re: Chrome crashing...

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.