fixed no_tint issue while rendering

[NavyaNayer]

Fix: Framebuffer Rendering Issue After noTint() Call

Resolves #7677

Summary of Changes

This PR fixes a bug where calling noTint() before rendering a framebuffer would cause an error and prevent correct rendering. The fix ensures that noTint() correctly updates shader uniforms without breaking the framebuffer rendering pipeline.

Key Fixes:

• Fixed framebuffer rendering failure after noTint() by setting its default value to [255, 255, 255, 255] (white) instead of null.

---

Bug Description

When calling noTint() before rendering a framebuffer, the following error was thrown:
Uncaught TypeError: Cannot read properties of null (reading 'slice')

This happened due to how noTint() was modifying the tint uniform value, causing the shader pipeline to fail when rendering framebuffers.

Root Cause:

1. noTint() was setting the tint value to null.
2. The shader uniform system attempted to slice the null value, resulting in an error.
3. This error prevented framebuffers from being rendered correctly.

---

Fix Implementation

The following changes were made to resolve the issue:

Updated noTint() Implementation

• Instead of setting tint to null, it now defaults to [255, 255, 255, 255] (white).
• This ensures valid uniform data is always provided to the shader.

---

Testing & Verification

Manual Testing

• Verified that calling noTint() no longer causes framebuffer rendering to fail.
• Confirmed that all tint-related operations function correctly.

Automated Testing

• Updated unit tests to validate correct behavior when noTint() is applied before rendering framebuffers.

---

PR Checklist

• [x] npm run lint passes
• [x] Inline reference is included/updated
• [x] Unit tests are included/updated

[welcome[bot]]

🎉 Thanks for opening this pull request! Please check out our contributing guidelines if you haven't already. And be sure to add yourself to the list of contributors on the readme page!

[davepagurek]

Hi @NavyaNayer! Sorry for the delay, I'm just getting time again to go through the issue backlog. It looks like part of the problem is that the WebGL renderer uses [255, 255, 255, 255] as the default value, but p5.Renderer2D uses null. If noTint() sets a non-null, tint, the 2D renderer goes down this code path (which is still visually correct, just slower): https://github.com/processing/p5.js/blob/8a13cf465746a7f6afac39bfba8861b59abccf25/src/core/p5.Renderer2D.js#L255-L257

I think this approach of using white as the default makes sense, but we maybe will need to update the above to check if the tint is just white, and possibly also edit the default value of the tint in p5.Renderer here: https://github.com/processing/p5.js/blob/8a13cf465746a7f6afac39bfba8861b59abccf25/src/core/p5.Renderer.js#L58