Framebuffer support for filter()

[davepagurek]

Increasing Access

• Speed: copying data between p5.Graphics in WebGL can be slow, and can prevent users from using filter() if the rest of their sketch is already heavier on performance, or needs to run on low-power devices like phones. If we can use framebuffers for WebGL canvas filters, we can let filters run at their maximum efficiency.
• Consistency: If we can run filters on framebuffers too, p5 will work more consistently across its different data types, and hopefully make this feature more predictable and easier to understand.

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build Process
• Unit Testing
• Internalization
• Friendly Errors
• Other (specify if possible)

Feature enhancement details

I think this has two components:

• In WebGL mode, running filters on a dedicated framebuffer instead of a dedicated canvas for maximum speed
• After doing so, make sure that filter() still works when in between a user framebuffer's begin() and end()

[opheliagame]

@davepagurek
I would like to work on this issue.
As you have mentioned and if I understand correctly, the p5.Graphics object needs to be replaced with a p5.Framebuffer object like so

 filter(...args) {
    // let pg = this.getFilterGraphicsLayer();
   let pg = this._getTempFramebuffer();
 ...
}

For the BLUR filter, the same way of getting a framebuffer should work and getFilterGraphicsLayerTemp() would not be required anymore.
I don't think I've understood the second step very well but would you let me know if I am on the right path as of now?

[davepagurek]

I think that sounds like the right path!

For part 2, the idea would be to be able to support something like the code snippet in this comment: #6502 (comment)

That may Just Work™ depending on your implementation for part 1, so probably don't worry about it until later, and then we can test it out 🙂