The real glory of it is the math – it’s using Webassembly to calculate the reference orbit, and then the GPU to calculate all the pixels, but with an enormous amount of fussing to get around the fact that shaders only have 32 bit floats. The interface works on mobile and desktop, but if you have any tips on how to polish it, let me know.
You could polish it by using variable size precision floats or at least quadruple size 128 bit floating point. This requires you to create a programming language compiler or use my parallel Squeak programming language (it is portable) and have that run on Webassembly or WebGL. It would be easier to have it run directly on CPU, GPU and Neural Engine hardware. The cheapest hardware today would be the M4 Mac mini or design your own chips (see my other post in this thread).
An example of this polished solution is [1] but this example does not yet use high precision floating point [2].
> to get around the fact that shaders only have 32 bit floats
I wonder if there are places around the set where rounding through the iterations depending on the number format chosen, materially affects the shape (rather than just changing many pixels a bit so some smoothness or definition is lost).
Have you considered publishing it under an open source license?
Then I could see myself working on some features like: Selectable color palette, drag&drop and pinch-to-zoom on mobile and fractional rendering (so that when you move the position, only the new pixels get calculated).
The real glory of it is the math – it’s using Webassembly to calculate the reference orbit, and then the GPU to calculate all the pixels, but with an enormous amount of fussing to get around the fact that shaders only have 32 bit floats. The interface works on mobile and desktop, but if you have any tips on how to polish it, let me know.