Idea: Consider supporting WebGL

[cauli]

Canvas is interesting, but it can be quite slow for more advanced rendering tasks.

There are a some frameworks like pixi that can render to WebGL with a nice API and fallback to canvas. It supports advanced Filters, Shaders. I've had a good experience with them in the past.

Thoughts?

[neauoire]

Ronin is not really built for speed, actually it's not even designed for livecoding, it's just a way for me to script little graphical action and do batch operation on image files. Speed is not super important at this point, and I don't like to include foreign code in my repos, but I will look into webGL, that might be fun :)

[Godje]

@neauoire , there are converters that will render the same way, just method names change a little bit. But it improves rendering speed a lot

[XiNNiW]

@neauoire, i love the idea of using fragment shaders in ronin to process images. For example, imagine a function called fragmentshader that would take in a string of shader code and return a shader object. Then imagine a function called runshader that would take a shader object and apply the shader to the current context.

You would be able to do things like import an image and run its pixels through any of the shaders behind the hydra functions, or through a fluid dynamics simulation.

It would also make it possible to re-implement some of Ronin's image processing functions in a way that can leverage the graphics card, all while only using vanilla js.

I took a shot at implementing this idea, just for fun. The results are on this branch.

I put an example of how this could be used for image manipulation here. I borrowed the shader code from hydra's kaleid function.

[neauoire]

Just checked your branch! It's pretty neat, it might be worth merging. Right now you've put everything in library.js which is meant to be only for the library functions for the lisp parser. Could you clean it up a bit and organize it so it's more like a module? Something like the surface.js file.

[XiNNiW]

Yeah, absolutely! Would surface.js be an appropriate home for these kind of image manipulation functions, or do you imagine a separate gl module?

[neauoire]

Let's make it a separate since the gl canvas has its own set of tools? I'm not sure, what do you think?

[XiNNiW]

I've been going back and forth in my head. All gl stuff needs to be done on a separate canvas as 2d context is incompatible with 3d context. However, if the goal is to use gl for 2d image manipulation and not for animation, then the 2nd canvas could be kept invisible and the images that result from the shader manipulation could be copied back to the main canvas. Putting it in surface.js makes it easier to move data between the gl canvas and the main canvas.

That being said, I think the above could be accomplished even if the gl code lived in a separate module, as long as that module had access to the other canvases.

Do you imagine using gl for purely 2d image manipulation or for creating 3d animation in Ronin?

EDIT: I started playing with both and I think I like making a separate module, which I'm calling glSurface for now. It makes the main surface code cleaner and easier to read.