It also has a "javascript fragment shader layer", so that you can evaluate GLSL code in CPU-land. This is pretty nice to prevent repeating things like coordinate transformation code, which turns out to happen all the time when doing mouse-picking in 3D, etc.
Another big win comes from writing your shader abstractions in Javascript itself. When you need to reuse bits of glsl here and there, you want 1) to pass around objects that are smarter than strings and 2) to configure the shader to behave differently when you have uniforms, attributes, textures, etc. Doing the heavy lifting in javascript and compiling down to GLSL really pays off here.
You shouldn't be using innerHTML to get your shader text, it'll break as soon as you put a comparison operator into the shader. Use textContent.
You should support using typed arrays instead of raw JS objects ({ x: , y: }) for setting vectors, since that will give people the option of using something like glMatrix.
In programming for OpenGL I don't mind the dancing with the state machine, but I hate the repetition and desynchronisation. The cognitive / ergonomic inefficiency wears me out pretty quick.
I know that Adobe's handling of the Flash Platform gets a lot of hate in these circles, but one thing I really enjoyed during my time there was writing shaders in PixelBender. Basically, it allowed you to write GPU-accelerated image filters in a GLSL-based language.
Most of the WebGL tutorials I've seen either require you to grok the entire OpenGL architecture or rely on something like THREE.js or ProcessingJS. It's really nice to see something in the middle (like PixelBender was).
Thanks!
(I've been keeping this in my to-read list. Seems to be similar, but in bare WebGL:
I said "abuse" because it is still a hack to use only one plain GLSL fragment for everything (a fragment shader aims to be used with a vertex shader, whereas mine is just static and take one vertex for the whole canvas). BTW, the glsl.heroku.com demoscene platform use exactly the same idea and was an inspiration.
The limit of this hack, is the fact that GLSL fragment uniforms number is limited (depending on the machine, 1024 variables on my macbook).
For instance, a `Ball ball[1000]` wouldn't compile because it is too much variables (if Ball has 2 fields). AFAIK, you could still solve this by using a big Array of float, but it would be less structured then.
If you just want to draw images into a canvas I don't see any benefits to using WebGL. You just lose cross browser compatibility. Most browsers have hardware accelerated rendering of 2d canvases. If you want to create unique shader effects, like blurs or masks or whatever, then there is definitely an argument to be made about the use of webgl.
Depends what you want to create I guess. Didn't Google show a 10x performance improvement for a 2D demo when done in WebGL compared to when it's done in canvas a Google I/O or two ago?
Plus, what do you mean by "most browsers"? Are you referring to IE? That's only included in IE9 and IE10, which is like what - 10% of the browser market? You can't include IE6-IE8 in that. So you're only getting about 10% extra market when you're thinking about creating a 2D web game as opposed to a WebGL game, but you lose a 10x performance improvement.
As for mobile browsers - do 2D web games get good performance on mobile? Is anyone even thinking about playing 2D web games on their mobile devices? I assume that even if they work okay, that's still only in the "high-end/latest" mobile devices, which is just a part of the whole smartphone/tablet market.
EDIT: Found it. They show the Microsoft fish demo at 1000 fish with canvas 2D, and then a WebGL version of it with 10,000 fish:
I was really thinking about mobile in terms of hw acceleration and risks/benefits. See comments below.
Don't disagree that WebGL is faster at times, and more useful, just still a bit immature. And I started working on it about 2 years ago so I know WebGL has matured greatly in a short period of time, but until it reaches a mobile browser I still see it as a bit too early.
Then again you could take those same shaders from a WebGL program and port the game/logic to iOS and so that may be an inherent benefit I am missing out on.
I disagree. You can very often just drop in webgl2d[0] into your Canvas based app and in most browsers see a performance boost, often a significant one.
WebGL-2D isn't even close to being a "drop in" replacement for Canvas 2D. It's still nifty though.
A closer alternative is https://github.com/phoboslab/Ejecta. That's using OpenGL ES 2, not WebGL, so there'd be some work to get it running with WebGL.
We can really do crazy effect with GLSL, easily and efficiently (with Canvas2D, we could use Canvas' ImageData for these effects but it is definitely less efficient).
For the compatibility, I would say it's getting better now, only IE is the browser which support Canvas but not WebGL.
But yes, if Canvas2d is enough for your needs, it's ok. Actually it would be interesting to inject a Canvas2d into glsl.js to add some cool effects on it :) I'm working on it!
Yeah sorry I was actually replying with a mobile centric view in mind. If you want to build something that "just works", it's better to strip down the geometry as much as possible and target canvas2d. The iOS implementation of canvas is hw accelerated, for example. However, you would not be able to target iOS for WebGL as of right now. So if you're looking to make something that is accessible, I would advice against WebGL. Do you disagree?
AFAIK, Safari only supports WebGL on the desktop, and behind a debug flag. I'd venture to say that Mobile Safari is more of an important browser at this point than old versions of IE.
"Most browsers have hardware accelerated rendering of 2d canvases."
Actually, you'd be surprised. For most users all the rendering is done on the CPU. The major exceptions are IE and Firefox (with non-blacklisted drivers) on Windows Vista or newer.
You're probably right. I was under the impression that Chrome wasn't shipping Skia GL on desktop yet, but my info could be way out of date; I haven't checked recently.
Cool. But when will browser games be taken seriously? I'd like to see it happen, but web-based games are still mostly considered something to do when you've got five minutes to spare.
It also has a "javascript fragment shader layer", so that you can evaluate GLSL code in CPU-land. This is pretty nice to prevent repeating things like coordinate transformation code, which turns out to happen all the time when doing mouse-picking in 3D, etc.
Another big win comes from writing your shader abstractions in Javascript itself. When you need to reuse bits of glsl here and there, you want 1) to pass around objects that are smarter than strings and 2) to configure the shader to behave differently when you have uniforms, attributes, textures, etc. Doing the heavy lifting in javascript and compiling down to GLSL really pays off here.