Mozilla

Live editing WebGL shaders with Firefox Developer Tools

If you’ve seen Epic Games’ HTML5 port of ‘Epic Citadel’, you have no doubt been impressed by the amazing performance and level of detail. A lot of the code that creates the cool visual effects you see on screen are written as shaders linked together in programs – these are specialized programs that are evaluated directly on the GPU to provide high performance real-time visual effects.

Writing Vertex and Fragment shaders are an essential part of developing 3D on the web even if you are using a library, in fact the Epic Citadel demo includes over 200 shader programs. This is because most rendering is customised and optimised to fit a game’s needs. Shader development is currently awkward for a few reasons:

  • Seeing your changes requires a refresh
  • Some shaders are applied under very specific conditions

Here is a screencast that shows a how to manipulate shader code using a relatively simple WebGL demo:

Starting in Firefox 27 we’ve introduced a new tool called the ‘Shader Editor’ that makes working with shader programs much simpler: the editor lists all shader programs running in the WebGL context, and you can live-edit shaders and see immediate results without interrupting any animations or state. Additionally editing shaders should not impact WebGL performance.

Enabling the Shader Editor

The Shader Editor is not shown by default, because not all the web pages out there contain WebGL, but you can easily enable it:

  1. Open the Toolbox by pressing either F12 or Ctrl/Cmd + Shift + I.
  2. Click on the ‘gear’ icon near the top edge of the Toolbox to open the ‘Toolbox Options’.
  3. On the left-hand side under ‘Default Firefox Developer Tools’ make sure ‘Shader Editor’ is checked. You should immediately see a new ‘Shader Editor’ Tool tab.

Using the Shader Editor

To see the Shader Editor in action, just go to a WebGL demo such as this one and open the toolbox. When you click on the shader editor tab, you’ll see a reload button you will need to click in order to get the editor attached to the WebGL context. Once you’ve done this you’ll see the Shader Editor UI:

The WebGL Shader Editor

  • On the left you have a list of programs, a vertex and fragment shader corresponds to each program and their source is displayed and syntax highlighted in the editors on the right.
  • The shader type is displayed underneath each editor.
  • Hovering a program highlights the geometry drawn by its corresponding shaders in red – this is useful for finding the right program to work on.
  • Clicking on the eyeball right next to each program hides the rendered geometry (useful in the likely case an author wants to focus solely on some geometry but not other, or to hide overlapping geometry).
  • The tool is responsive when docked to the side.

Editing Shader Programs

The first thing you’ll notice about Shader program code is that it is not JavaScript. For more information on how Shader programs work, I highly recommend you start with the WebGL demo on the Khronos wiki and/or Paul Lewis’ excellent HTML5 Rocks post. There also some great long standing tutorials on the Learning WebGL blog. The Shader Editor gives you direct access to the programs so you can play around with how they work:

  • Editing code in any of the editors will compile the source and apply it as soon as the user stops typing;
  • If an error was made in the code, the rendering won’t be affected, but an error will be displayed in the editor, highlighting the faulty line of code; hovering the icon gutter will display a tooltip describing the error.

Errors in shaders

Learn more about the Shader Editor on the Mozilla Developer Network.

Here is a second screencast showing how you could directly edit the shader programs in the Epic Citadel demo:

17 comments

Comments are now closed.

  1. kris wrote on November 12th, 2013 at 10:59:

    Victor’s face is much look as chris at opera :)

    1. Jsx wrote on November 13th, 2013 at 04:28:

      Chris is now at Mozilla o_O

  2. Aras wrote on November 12th, 2013 at 11:20:

    Thanks for this update, the shader editor looks very useful and very cool! Having the option in the developer tools totally makes sense. I dont know how feasible that is but I wonder, would it be possible to have an automatic mode to add shader tab when the page contains WebGL, and remove it for pages that don’t. I think that would be a cool feature, and the UX for doing that can probably be re-used for simillar tools that only apply to certain group of apps/pages.

    1. Victor Porof wrote on November 12th, 2013 at 11:23:

      That certainly makes sense. We’ll look into showing the tab by default on pages with WebGL content.

  3. foxtrot wrote on November 12th, 2013 at 11:30:

    Great stuff. And now I’m waiting for CSS shaders!
    Please make it happen guys.

    1. Dusan Bosnjak wrote on November 14th, 2013 at 15:48:

      What are CSS shaders?

      1. foxtrot wrote on November 15th, 2013 at 13:28:

        The idea is to use vertex and fragment shaders as custom CSS filters.
        See here: http://www.adobe.com/devnet/html5/articles/css-shaders.html#articlecontentAdobe_numberedheader_0

  4. Andy wrote on November 12th, 2013 at 14:03:

    This is awesome! Does opengl provide the shader compilation errors, or are you guys rolling your own syntax checking / parsing?

    1. Victor Porof wrote on November 13th, 2013 at 00:10:

      Compilation errors are provided by the driver. See http://www.khronos.org/opengles/sdk/docs/man/xhtml/glGetShaderInfoLog.xml

      1. Benoit Jacob wrote on November 14th, 2013 at 12:40:

        In fact, they are rather (in most cases) provided by the ANGLE shader compiler, which is what we use on all platforms to validate shaders and translate them to WebGL’s dialect of GLSL to regular GLSL (or HLSL on Windows).

  5. pd wrote on November 13th, 2013 at 11:06:

    Good to see DevTools breaking new ground and complimenting Firebug.

  6. Luke wrote on November 13th, 2013 at 20:43:

    Wow! Will this work regardless of the method of drawing (asm.js library, ThreeJS, etc.)?

    1. Victor Porof wrote on November 14th, 2013 at 03:25:

      This tool should work with all WebGL content.

  7. Patrick Cozzi wrote on November 16th, 2013 at 20:16:

    Very nice work here. I tried this on our engine and I am happy that this works for real apps, not just demos.

    A few feature ideas that would make it even better:
    * Bold code in #ifdef blocks that evaluate to true.
    * Mouse over a pixel and show the shader used. Mouse over a pixel and show a profile of the fragment shader. No problem, right?
    * An option to see only shaders used in a frame, instead of all shaders in the WebGL context, since many shaders may be for culled objects. Taking it a step further, the display could be decluttered more by only showing shaders for non-occluded fragments.

  8. makc wrote on November 21st, 2013 at 10:56:

    So the tool is great, everyone appreciates this, really cool, and thank you.

    Now let me just skip to the bad part… I don’t know if this was mentioned anywhere, but currently there is nothing in the editor to show you which #ifdef-s are active. E.g. if I try to open any threejs demo, I have lots of conditions there, and it is not immediately obvious if particular code is active. I need to go up and check every condition against #define-s at the top. This is terrible :) Can something be done about this? maybe simply out inactive sections of the shader in grey, like comments? Any solution to this problem would make it perfect!

    1. Victor Porof wrote on November 25th, 2013 at 08:53:

      It should be possible to remove unused code, similar to how unifdef works: http://dotat.at/prog/unifdef/

      Filed this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=942855 Feel free to contribute if you have the time :)

      1. makc wrote on November 25th, 2013 at 09:18:

        Yes, that is good option, too. Since I guess the shader is not going to be just copy-pasted from shader editor any way, only specific parts will be edited by hand.

Comments are closed for this article.