Why processing still only supports float precision coordinates? Is there an obvious reason why not to support double data type alongside with float? If there was a reason back in the early days, this was hardware specs, CPU power, RAM etc, I guess this reason seems obsolete right now.
How difficult would it be, to alter the entire codebase, in order to support the double data type, and of course, keep float for backwords compatibility?
I think this feature can be considered an obvious upgrade for a next future version. There is criticism about this limitation, a related, interesting article can be found here: Why I switched from Processing to OPENRNDR | by Jonathan Ellis | Medium
1 Like
Given Processing is just a slightly modified Java, workaround is very simple:
Suffix every floating literal w/ d and replace Processing’s math functions w/ Java’s Math:
https://docs.Oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Math.html
But when using PVector & PShape objects at the end, their coordinates will be always float, right? I guess this math workaraound is for “internal” calculations only ( functions like sq() ), output will be always in float. Coordinate conversions between Graphics2D double precision objects (e.g Path2D.Double) will have obvious issues in complex shapes, so interaction with Graphics2D suffers by this limitation.