Depth peeling successfully implemented in WebGL

In the easy-to-use WebGL-based GlowScript 3D programming environment ( you can now specify the opacity of an object (other than curve, ring, and helix). The following statement creates a cyan-colored cube that has low opacity (high transparency):

box( {color.cyan, opacity:0.2 } )

Here is a demo: … ansparency

The technique used is “depth peeling” which correctly handles transparency at the pixel level. Simpler transparency schemes, in which objects are ordered back-to-front on the basis of their centers, fail to make the correct display if, for example, two transparent objects intersect each other.

The open source is at In the Source folder the key files are lib/glow/WebGLRenderer.js and the shader files which are found in the shader folder.

I’ve discovered to my chagrin that this depth peeling transparency scheme fails on some platforms, and it apparently is a graphics driver issue. Until a few days ago, I was using only a few shader programs, each with many if statements. I was experiencing long shader compile times, and colleagues pointed out to me that compiling if statements is very slow. So I changed to having 10 specific-purpose shader programs rather than 4 general-purpose ones, which significantly cut the total shader compile time. However, now I get black canvases on some platforms. It’s clearly a driver issue, because on a dual-boot machine (Windows and Ubuntu Linux 11.10) I get a black canvas on Linux and everything’s fine on Windows. (As usual, trying to update an nVidia graphics driver on Ubuntu is problematic, though I’ll keep trying.)

I realize that there may be some gl parameter I can test and then relapse to opaque objects, but it doesn’t seem like going from 4 shaders (always loaded) to 10 shaders should matter, especially when typically only 6 of these 10 are loaded; the others are loaded only on demand, for special purposes such as picking or for rendering special objects that don’t appear in the demo programs that show the problem.

Where do I report a WebGL problem of this sort?

Upon further investigation, I’m convinced it’s a driver problem, not a WebGL problem. In addition to other evidence, it’s highly suggestive that the problem arises specifically in environments where it is difficult or impossible to update the graphics driver: MacBook Pro and Ubuntu. I may be able to implement a workaround, because transparency worked on a MacBook a week ago, when my architecture was a bit different.