Graceful accuracy falloff without checksum bits & compatible with Brave

[exrhizo]

I went on an adventure, wondering what the method for distributing points that would minimize collisions would be.

I expected anti-aliasing blending ought to be linear, in that black and white would blend to grays, however this didn't seem to be the case in practice, when I tested it, see Stack Exchange

Finally, I landed on using a bit reversed z-order curve to index the color space, the intuition being that more spread out colors would collide less likely than tightly bunched colors blending.

By reversing the bits, it was easy to ignore the lowest bit for each channel in brave.

Also, I removed tiny color, the min.js went from 14kb -> 3kb

Here is a codepen I made as I tested it

TODO: Have examples point to unpkg

[vasturiano]

@exrhizo thanks for putting in all your work to figure this out. I hope it's been a fun research. 😃

About merging the changes, given that it adds a lot of complexity to the codebase, and entangles it with a benefit for only a specific browser setting (fingerprint logging in Brave), I'm leaning towards suggesting that it would be perhaps better to have your version as a stand-alone fork of this repo, rather than merging the two.

Does that seem reasonable?

[exrhizo]

You're maintaining the codebase, it's your call - I am going to install the fork in my codebase now.

I tried to find a simple solution that could improve the algorithm - I see what you mean about complexity.

The project I am working on is for crypto related community tool, a lot of our users are using Brave, as they are more privacy conscious and expect their default config to work.

Perhaps other's will want support for Brave in the future.

Overall, I think that it is harder to understand, but good enough relative performance and like I titled this doesn't require pre allocating bits to be for error correction, although in practice, I imagine millions of objects are rare, and less code is easier to maintain.

[exrhizo]

Someone contacted me about running into the same problem, I notice 3 other people

This change adds 150 lines to the actual main code and removes a dependency, tinycolor2, and it has been used in production for over a year for Coordinape without issues, with at least 1000s of users.

[jordoh]

To chime in here, we've run into this in our application using the force-graph library, and this does appear to be a default Brave setting. Asking our users to drop shields in Brave works, but is a clunky workaround that only helps those that reach out to our support and are willing to do so. While I'd certainly argue that Brave shouldn't be breaking APIs for hand-wavy "protections", as a user of force-graph it would be nice to have this fixed - or at least to have had a warning (in the readme) that force-graph isn't fully functional in Brave.