Fixes #9000

[NalinDalal]

Resolves #9000

set() on p5.Graphics was significantly slower in 2.x vs 1.11.x because
_getRGBA did a full to('srgb') + structuredClone + map() on every
call, even when the color was already in RGB mode and being reused in a
tight loop.

Changes:

1. Cache _getRGBA results
   • Added #rgbaCache Map on Color, keyed by maxes string
   • First call computes and stores; subsequent calls with same maxes
     return a shallow copy of the cached array
   • Cache is invalidated in setRed, setGreen, setBlue, setAlpha,
     and the _color setter
2. RGB-mode fast path
   • When this.mode === RGB, coords are already sRGB 0-1, so skip the
     to('srgb') conversion and use [...this._color.coords, this._color.alpha]
     directly
   • Non-RGB modes still go through colorjs conversion

AI usage disclosure: I used Kilo (an AI coding assistant) to help
implement and review this change. I understand and take responsibility for
every line of code in this PR. See [AI_USAGE_POLICY.md].

PR Checklist

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

[ksen0]

To show that this fixes the original issue, please report results from the linked benchmark test, at minimum. Thanks!

[NalinDalal]

Confirmed the fix in 88e1550 — benchmark (100×100 buffer, 50 iterations, Brave):

• Average: 2.41 ms
• Min: 1.90 ms
• This matches the v1.11.12 baseline of ~1.85 ms, down from the reported 12.79 ms in 2.3.0.

Hope this resolves your query @ksen0

[perminder-17]

The results are good, just one concern for the cleaner code.

[perminder-17]

I don't think we need this Map(). The only heavy step is the 'srgb' conversion you did above, so we can just cache that part, less complexity and cleaner code.

[Ayush4958]

maxes.join(',') allocates a new string on every call inside loops. Using a fast path key check for [255, 255, 255, 255] avoids string allocations during pixel loops.

[Ayush4958]

Use this._color.space.id === 'srgb' instead of this.mode === RGB makes the fast-path work for any color object backed by sRGB. It ensures that any color whose underlying color space is sRGB will bypass colorjs conversion and structuredClone, even if the color mode was initialized via another path.

[NalinDalal]

All feedback are addressed and solved, thanks for your input @Ayush4958 and @perminder-17

[ksen0]

Nice work, thanks ! And thanks to reviewers!

[perminder-17]

Looks good to me!

[p5-bot]

Continuous Release

CDN link

• https://raw.esm.sh/pr/p5@4bbd1e6/lib/p5.min.js

Published Packages

• https://pkg.pr.new/p5@4bbd1e6

Commit hash: 7f4b60a

Previous deployments

---

This is an automated message.

[limzykenneth]

If I read the changes correctly, is it essentially memoizing the _getRGBA function? The implementation should be ok and functional but having a #invalidateSrgbCache can be a bit brittle in that we need to make sure that #invalidateSrgbCache is called on all possible code paths (including in the future) that changes the color somehow. If it is just some form of memoizing, can we create a memoization whose key is the color coordinates? Similar to what toString() uses ${this._color.space.id}-${this._color.coords.join(',')}-${this._color.alpha}-${format}?

[limzykenneth]

This file shouldn't be committed as it does not match the required format of the benchmark harness.

[limzykenneth]

Looks good for now. If you can do a test with benchmarking to see if it affect performance or not that would be great. After that we can merge.

[limzykenneth]

Good to have this. I wonder if 1000 is the right number? What would a typical number of colors set() would manipulate and what would be a sensible upper bound without it leaking memory?

[NalinDalal]

Typical sketches use far fewer than 1000 unique colors. However, image processing or complex generative art could exceed this. Each entry is small (~32 bytes), so 1000 entries ≈ 32KB max. I chose 1000 as a conservative default that covers most cases without significant memory impact. Would you prefer a different value or should we make it configurable?