Double precision support for all fundamental geometry classes (PShape, PVector ...)

[istinnstudio]

Relevant sub-area for this feature?

Core/Environment/Rendering

Feature description

When using PShape and PVector calculations alongside with native Path2D.Double objects (using various conversions) there are obvious, randomly appeared but systematic rendering artifacts - rounding errors (same result when using same parameter values) upon all kinds of calculations, transformations etc. With all that CPU processing power around, I guess there is no practical reason of not adding Double coordinate support for all classes without braking compatibility with existing projects.

Benefits

Use PShape and PVector classes alongside with other classes that support natively double precision coordinates like Path2D without precision errors. Future proof Processing projects.

Possible challenges

I do not have a clue what might be the impact in codebase. I guess there should be a compatibility code care for all existing projects and default will be Float.

Additional context

An Article about the precision artifacts: https://blog.generativedarkroom.com/why-i-switched-from-processing-to-openrndr-b50c931d21ae

[micycle1]

There's a strong case for this change, for geometric and trigonometric operations. However it would break compatibility with older sketches if users have declared the results of PVector operations and such as float... Wouldn't bother me, but something to consider. Otherwise, it's an easy change to the codebase.

Amazingly, if you generate 100,000 floats between 0 and 1, you'll get about 300 pairs of value collisions! And 1,000,000 gives 30k collisions!

[istinnstudio]

I have successfully created a double version of the library by brutally replacing "float" to "double" and then doing some polishing. At the end, using java2D renderer, all sketches I have tested, work ok by casting back to float or by replacing "float" to "double". As there are thousands of float references in codebase and some very common methods rely on them like "ramdom" it is a bit of an effort to support both without braking all existing sketches. Also there are color references that should, I guess, stay float as it is for native java, color bit depth is a different subject. But spatial data have a more profound prone to calculation artifacts. Also openGL renderers, I guess, should stay float anyway for the GPU internal architecture but I am not sure.