glsl.js - abusing WebGL shaders for efficient 2D

http://blog.greweb.fr/2013/02/glsl-js-a-javascript-glsl-library-dry-efficient/

by gren • 13 years ago

107 24 13 years ago

blog.greweb.fr

AnthonBerg• 13 years ago

I really like that this is DRY.

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.

This is very very nice. Hats off.

shurcooL• 13 years ago

I couldn't agree more. Props for DRY.

podperson• 13 years ago

I don't think "abuse" is the correct word. "use" is the correct word.

gren4• 13 years ago

some precision here:

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.

msvan• 13 years ago

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.

cscheid• 13 years ago

Cool! I've been building something similar: https://github.com/cscheid/facet (demos: http://cscheid.github.com/facet/demos/index.html)

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.

kevingadd• 13 years ago

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.

gren4• 13 years ago

Woo, thanks a lot for your feedback :)

I'll fix that ASAP.

[EDIT] all of the issues are now on github: https://github.com/gre/glsl.js/issues

erichocean2• 13 years ago

+1 on typed arrays. Anything that supports WebGL should also support them.

alexhaefner3• 13 years ago

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.

gren4• 13 years ago

See http://glsl.heroku.com/ and also my Pong example http://greweb.fr/glsl.js/examples/pong/

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!

bsimpson2• 13 years ago

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.

alexhaefner3• 13 years ago

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?

mtgx• 13 years ago

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:

http://youtu.be/MiYND_zvIc0?t=14m3s

alexhaefner3• 13 years ago

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 do understand it's a bit of a mixed bag :)

pcwalton2• 13 years ago

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

comex• 13 years ago

Huh? Both Safari and Chrome support hardware acceleration of 2D canvas.

city41• 13 years ago

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.

[0]https://github.com/gameclosure/webgl-2d

erichocean2• 13 years ago

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.

Skoofoo• 13 years ago

I enjoyed the Pong demo, it's pretty inspirational. The Mario sprites demo appears to be broken, though.

gren4• 13 years ago

Thanks.

Yep, about the mario sprites example, there is something I'm missing happening https://github.com/gre/glsl.js/issues/2

It works for me (tested on MacbookPro and on a Linux with recent hardware)

I have to figure it out.

[edit] It is fixed now! sampler2D in a struct{} seems broken on some WebGL version / graphic card.

bsimpson2• 13 years ago

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:

http://dev.opera.com/articles/view/webgl-post-processing/

)

iknownothing• 13 years ago

Every time i visit the site it kills my display driver when using Firefox. No problems with chrome though

glsl.js - abusing WebGL shaders for efficient 2D

Related Stories