Antialiased framebuffer performance improvement

[davepagurek]

Increasing access

Currently, antialiased framebuffers draw more slowly than non-antialiased ones. It's not obvious to users where this performance hit happens, and it's much more significant on lower end devices. It's possible to improve this performance without affecting behaviour at all, so lower end devices will get better performance with no negative impact.

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
• Internationalization
• Friendly errors
• Other (specify if possible)

Feature enhancement details

Under the hood, only WebGL RenderBuffers can be antialiased. You can write to those but they can't be read as textures. So when using an antialiased p5.Framebuffer, under the hood, we draw to a RenderBuffer, and then copy its data to a regular WebGL texture so that it can be used like an image in the rest of p5.

However, we do this after every draw block finishes. So this will copy data once:

myFbo.draw(() => {
  for (let i = 0; i < 1000; i++) {
    circle(random(-1,1)*width/2, random(-1,1)*height/2, 20)
  }
})
image(myFbo, -width/2, -height/2)

...but this will copy the data 1000 times:

for (let i = 0; i < 1000; i++) {
  myFbo.draw(() => {
    circle(random(-1,1)*width/2, random(-1,1)*height/2, 20)
  })
}
image(myFbo, -width/2, -height/2)

The difference between those might not be obvious to users, but the impact is significant between antialiased and non-antialiased frameworks. e.g. on my computer, this drops from 50ps to like 5 when turning on antialiasing: https://editor.p5js.org/davepagurek/sketches/Y6mB3IOOz

This can be resolved by only copying the data when the texture is about to be read. For other texture sources like p5.Image, we only copy new data into a texture when the content has changed. The same approach could be used here.