WEBGL anti-aliasing different rendering results regarding anti-aliasing/alpha blending in latest p5.js version

[mheesakkers]

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)

p5.js version

1.6.0

Web browser and version

Chrome (Official Build) (x86_64)

Operating System

Mac 13.3.1 (a)

Steps to reproduce this

I created a topic about this on Processing's discourse about my problem because I thought I was doing something wrong.

In short. I created a shader program in the p5.js editor that does color mixing (also transparancy) using spectral.js. When I tried implementing that shader in my local project I got some weird anti-aliasing artefacts. After a lot of digging I saw that the online editor uses the p5.js 1.4.1 version and I was running the latest version 1.6.0 locally. Changing the library version to an older one resolved my issue.

Result comparison (zoomed-in)

On the left using p5.js 1.41, on the right p5.js version 1.6.0

See link to the program in the p5.js editor:
Link to shader program in p5.js editor

Steps:

1. Go to index.html and change the p5.js version inside the head tag of index.html to 1.6.0
2. Run the sketch and see the anti-aliasing artefacts
3. Change the version back to 1.4.1
4. Run the sketch and see a nice and clean looking result

I'm not that technical so I could not provide where the culprit in the p5.js library would be or if this would be the expected behaviour. Hope this can be fixed in the latest version of p5.js.

[welcome]

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, please make sure to fill out the inputs in the issue forms. Thank you!

[aferriss]

There were a few changes related to webGL alpha handling in the past 6mos, which may account for why you're not seeing the issue on older versions of p5. Probably something unintended found it's way in, blending is a difficult area to debug.

#5683
#5917
#5794

Maybe @davepagurek can help to debug.

[aferriss]

I think this is likely a pre-multiplied alpha issue, so adding the following line to the end of your shader should hopefully fix things:

gl_FragColor.rgb /= 1.0/gl_FragColor.a;

We should definitely still look into why this is happening though.

[davepagurek]

Thanks @aferriss for the quick reply, this is indeed caused by premultiplied alpha!

In your sketch, if I switch to v1.6.0, it looks normal to me if I replace the end of your main routine with this:

  if (col.a > 0.0) {
    col.rgb *= col.a;
    gl_FragColor = col;
  } else {
    discard;
  }

This was an intentional change introduced in #5917 to change the way we store colors on canvas. The key difference is that all color channels get scaled down by the opacity of the pixel. This was done because if the canvas itself has a transparent background, the transparency gets incorrectly blended otherwise. It unfortunately means that shaders written before that change will need to be updated to work with the new version, but as a consequence, but we opted to make a breaking change in order to enable all those features to work in future versions.

[mheesakkers]

Thanks both (@davepagurek / @aferriss ) for the quick replies. I tried adding the multiplying by alpha to my shader using version 1.6.0. The result gets better but when I zoom-in the result is still different, a bit more jagged. See:

Link to sketch
https://editor.p5js.org/Misha.studio/sketches/w6YnJlHG7

[davepagurek]

It looks like the subtle differences happen from repeated rendering. Each time we store the canvas in premultiplied alpha, we're storing the product of the color channels with the alpha, meaning there's slightly less precision in the color. I added this line right before the if (col.a > 0.0) check:

if (col == t1) discard;

Here's the difference it makes (you'll probably have to click to open the images and zoom in):

Before	After

What this is doing is not re-writing the colors if the shader thinks the output color should be the same as the current destination color. Avoiding re-writing the color means avoiding storing round(col.rgb * col.a * 255.0) again, where that repeated rounding might cause some colors to shift (but maybe not all of them to the same extent, as some color/alpha combinations might be more stable to repeated rounding.)

So this isn't the only issue we see with feedback textures, as even without multiplying by alpha and rounding, we still see issues just from rounding to 256 values per channel. I think the longer term solution for shaders like this, once we release the next version of p5, would be to use a framebuffer with a float texture to avoid doing any rounding, which I suspect will also mitigate this issue.

[mheesakkers]

Thanks for diving into this and explaining what is happening! - I think I understand right now what's going on and indeed your proposed addition to the shader code gives a result that is closer to the 1.4.1 result. I think I stick to the 1.4.1 version for now because it's slightly smoother. Should I close this issue?

[davepagurek]

Sounds good, let me know if you have any other questions 🙂