Performance improvements for colors

[davepagurek]

Addresses #8316

Changes:

• Introduces a concept of a defaultStringValue: if present, just return that instead of going through colorjs. That gives us an opportunity to add some custom faster logic in key places.
• Makes the assumption that, if you've created a color with a string, as long as we're in the same color mode that you created the color in, we can directly use that string in a CanvasRenderingContext2D, so if you create a color that way, we can use the string directly as the defaultStringValue
• Also creates hex strings for colors created with number inputs in RGB mode for faster output. (For colors with alpha, it uses 8-digit strings since this seems to get parsed faster than rgba.)
• Updates the creation of the _color object to be lazy: it only gets created if we need it, e.g. if we're converting between color modes. This saves a little time in less complex cases.
• Adds a size limit to the cache of serialized color values. If the object gets too big, adding another color to it throws an error and breaks the sketch. Now, it's a Map where we can quickly see its size and remove items if need be.

Live: https://editor.p5js.org/davepagurek/sketches/UG6fwp2hc

In this test sketch, I get 40fps where in 2.1.2 I get 12fps. Note that in 1.11.1, it still achieves >50fps though. But it's an improvement.

PR Checklist

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

[limzykenneth]

I may need to double check but I think this.mode is not supposed to be modifiable after creation of the object (the comment might be a bit confusing there). This is because the underlying color.js object is created in a specific space that correspond to a mode, changing a p5.Color object's mode does not change the underlying color.js object's space, and I think it shouldn't either since the behavior of p5.Color from 1.x is that the color mode stays with the color object which is the case for 2.x as well. This could make the implementation simpler?

[davepagurek]

I think that'd mean we can take out the mode setter, but it looks like the mode value is based on info in the parsed colorjs object, so we likely still need it to be lazily evaluated if we want to avoid parsing until it's necessary so that simple cases can skip it.

[limzykenneth]

I see there are some parsing needed to get the additional information like mode when passed a string. I think this should be fine for now and we can continue to optimize as needed.

For the performance, I'm not seeing much difference between the custom build in the linked sketch and 1.x on my machine, I find framerate usually not a very good indicator, but we can benchmark in more detail as well later.

[davepagurek]

That's good if it's hitting the same frame rate as 1.x for you at least! Is something like this safe enough to merge as is or do you think this warrants more benchmarking and testing?