Export to GitHub

quake2-gwt-port - issue #26

Firefox (dev branch) blocked, "WebGL support required"


Posted on May 15, 2010 by Helpful Giraffe

Hi, I'm working on WebGL at Mozilla, we have lots of recent improvements and I was interested in using Quake2 as a test to discover more things to fix, but I can't, as it makes me land on the "WebGL support required" page.

Comment #1

Posted on Jun 3, 2010 by Helpful Giraffe

Ok, I had a look at the source, and it seems that you're not blocking Firefox, sorry! It's just that, if I understand the code correctly, you're throwing exceptions on every GL error, and we hit GL errors on Firefox :) Unfortunately this makes it super hard for me to debug, as the GL errors don't get a chance to show up in the error console. Can you help me by telling me how to disable this behavior?

Comment #2

Posted on Jun 7, 2010 by Helpful Giraffe

Update. Here in Firefox (Minefield), Quake2-GWT does not even attempt to create a WebGL context. Yet the error page says "WebGL support required". So at the very least, the error message seems wrong :)

Comment #3

Posted on Jun 19, 2010 by Swift Bird

same here i'm using Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a6pre) Gecko/20100618 Minefield/3.7a6pre and i activate webgl via about:config. some webgl demos work fine but my local quake2-gwt just shows typical error page (webgl support required ....)

in error console i found no error or warning. there is no entry at all.

Comment #4

Posted on Jun 22, 2010 by Helpful Giraffe

This has been further investigated; it turns out that the reason is that quake2-gwt is trying first the "webgl" canvas-id, without trying to catch exceptions. We don't support the "webgl" canvas id, because the WebGL spec is not yet final, so with other browser makers we agreed to support the "experimental-webgl" canvas id. So what happens is that when quake2-gwt tries "webgl", we throw an exception, and it isn't caught. Quake2-gwt really needs to be fixed: it shouldn't assume that trying the currently illegal "webgl" id won't cause an exception. See e.g. how it's handled in the WebGL conformance tests: exceptions are caught (and "experimental-webgl" is tried first):

https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/resources/webgl-test.js

function create3DContext(canvas) { if (!canvas) canvas = document.createElement("canvas"); var context = null; try { context = canvas.getContext("experimental-webgl"); } catch(e) {} if (!context) { try { context = canvas.getContext("webkit-3d"); } catch(e) {} } if (!context) { try { context = canvas.getContext("moz-webgl"); } catch(e) {} } if (!context) { throw "Unable to fetch WebGL rendering context for Canvas"; } return context; }

Editing quake2-gwt to try "experimental-wgl" first (or catch exceptions), and other tweaks, allow to get all the way to the game main menu, where we stop on another exception, caused this time (as far as I understand) by quake2-gwt converting all OpenGL errors into exceptions (which pretty much guarantees that no other experimental webgl implementation than webkit's can run it, since the GL error reporting hasn't yet been fully harmonized across WebGL implementations --- we're working on that closely with google and apple on the public_webgl list, but that takes time).

See this for further info & discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=557423

Comment #5

Posted on Jun 22, 2010 by Helpful Giraffe

Update: with the patch by Barak, (attached to https://bugzilla.mozilla.org/show_bug.cgi?id=557423) quake2 is actually running in Minefield! So what I wrote above about GL errors was probably wrong.

Comment #6

Posted on Jun 23, 2010 by Helpful Giraffe

a firefox howto can be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=557423#c44

Comment #7

Posted on Jul 5, 2010 by Happy Wombat

Hi,

thanks for looking into this!

I have changed the WebGL context creation code (try/catch block, experimental-webgl first) and added a check whether the console is present before logging to the console. However, I still get the error message in FF (Minefield/3.7a5pre GTB7.1). Not sure why the console is not present despite firebug...

Is there anything else we can do on our side to make this work in minefield?

Stefan

Comment #8

Posted on Jul 6, 2010 by Happy Horse

Hi Stefan, I wrote some of the patch that Jacob linked to (sorry for all the mess :)). Anyway, I had the same problem you have, I assume you're using the latest Firebug development version from http://getfirebug.com/releases/firebug/1.6X/?C=M;O=A For whatever reason the latest version doesn't seem to "kick in" after enabling the console (I'll probably file a bug on that- if there isn't one already open) - I have no idea in which version this regression happened so I just use the first development version there (firebug-1.6X.0a1.xpi)... it seems to work fine

If you need any more info feel free to page me :)

Comment #9

Posted on Jul 6, 2010 by Happy Wombat

Ah, sorry, somehow had overlooked the diff: https://bug557423.bugzilla.mozilla.org/attachment.cgi?id=453036

The main problem is that it seems a bit aggressive, i.e. it looks like it may break Chrome -- and it contains a lot of stuff that is commented out. So I cannot just patch it in and commit the new code... I will try to carry over some more of the changes during the next days. Of course any help (like a cleaner patch that has some kind of "if (firefox)" where necessary) is welcome! :)

Comment #10

Posted on Jul 6, 2010 by Helpful Giraffe

Hi, Thanks Stefan for handling this; not much to add since smoohta==Barak is the author of the patch :)

I hope a good cross-browser solution can be found; Stefan: you can easily test code in Minefield by using nightly builds.

Comment #11

Posted on Jul 6, 2010 by Happy Horse

Stefan- I know, that's what I meant by the "sorry for all the mess" comment :)

Here is a much much cleaner patch, a couple of notes: 1. As you can see the main change is in render/gl/Main.java - wrapped with (isFirefox) as you suggested. Another change in Main.java is a check before the gl_config.extensions_string is parsed (since Firefox doesn't expose the client's GL extensions) - the diff makes it look awful but all it is a if (gl_config.extensions_string != null) before and an else { ... } after :) 2. At some point, Firefox switched from getting GL Parameters through glGetString to glGetParameter (per the WebGL specification, as Jacob explained it) so I've added a glGetParameter method to the GLAdapter class (to complement/replace glGetString). Depending on the nightly version you may or may not need to use this method instead of the former... 3. If you're using the Firebug console to debug, the game will work fine until you try to start a game. This is because Firebug/Firefox currently has a bug- if Firebug is enabled XHR callbacks aren't called (see Firefox bug if you're interested) so all the resource loading won't work unless you disable Firebug :( Another problem is that for some reason, the "default" generated code has a call for Console (haven't found where) so the current workaround is to strip out all the Console calls out of the generated HTML before running the server (see Jacob's link).

Attachments

Comment #12

Posted on Jul 6, 2010 by Happy Wombat

Hi Barak, thanks for the updated fix! A lot of issues should be gone if you update to mainline. In particular, I have added a check wether window.console is there before using it. I'll take a look at the getString vs. getParameter issue.

Comment #13

Posted on Jul 7, 2010 by Happy Wombat

Update: Works in current nightly of Minefield/4.0b2pre now.

Thanks again for the hints/patches!

Comment #14

Posted on Jul 7, 2010 by Happy Horse

Sure, great to see it working out of the box :D

Thanks for fixing this properly :)

Comment #15

Posted on Jul 7, 2010 by Helpful Giraffe

Wow, this is awesome indeed!

I'm at the Mozilla Summit right now, people will love this :)

Status: Fixed

Labels:
Type-Defect Priority-Medium