Interesting idea! @aferriss has already done most (all?) of the hard work for this in this repo.

Typically, I would direct a student to this repo when I was suggesting this route. But perhaps it is worth the addition to library size (likely small) to have these as p5.Shader constants.

Performance is really important to consider right now and definitely falls under the umbrella of accessibility. Working with students through Zoom, I am painfully aware of the hard limits that students are hitting with performance. This is exacerbated by the fact that many students are using home computers for the first time when they have used school lab computers (which often have superior hardware) in the past.

For sketches that rely heavily on images with filters, the performance gains with WEBGL and shaders will be very significant.

Interesting idea! @aferriss has already done most (all?) of the hard work for this in this repo.

Exactly -- I think it would largely be a question of syncing up the names. And seems a good thing to do whether or not we want to have them invoked automatically when using the GL renderer.

This sounds like a great idea to me! 💜

Hey, I would like to help with that issue, would just the .vert and .frag files be enough? Or do I have to convert them somehow into Shader object?

@JalokimFreelance i think that would be enough! i'm 90% sure we already have some build process for inlining shader files into the p5.js lib.

I spent some time looking at how this might work. What do you think of the approach here?

The shaders for each filter would be files that are handled the same way as other default shaders.

The method applyFilter(filterType, filterParam) would be provided and it would behave the same as filter() in a 2D context.

(applyFilter could also just be called filter, and then the appropriate method called behind-the-scenes following a check of whether the current canvas is 2D or 3D).

Update:

Here is a more robust version that creates a new canvas/buffer via createGraphics() to perform the filter.

@stalgiag What do you think?

Thanks for the draft @JetStarBlues !

I think using filter is a good idea. Your second implementation looks great to me but I am very curious whether get() is going to be a bottleneck. I am getting a low framerate on the example but it is unclear how much of this is caused by creating the shader in applyFilter. I think this is worth pursuing for now and we can see how performance shakes out once a draft PR is made.