core.stroke and core.fill perform poorly because of save-current- functionality

[sbenhaim]

Both stroke and fill save their current state to the internal-state atom, which causes a significant performance penalty compared to their native implementations when called many times in the draw function.

I discovered this when porting a Java implementation that called stroke within a nested loop 32^3 (~33k) times per frame (to draw a 32 x 32 x 32 point cube). Performance was miserable compared to the Java version.

Digging in, I discovered stroke was the culprit, and more specifically, the call to save-current-stroke. With the current implementation, the code ran at around 1.5 fps on my machine, compared to 40 fps with the call to save-current-stroke removed.

fill appears to have this same problem.

Perhaps this should be an opt-in feature, unless there is a way to implement this global state tracking without the performance penalty.

[sbenhaim]

Here is an example of code that runs at <2 fps on my machine:

(defn draw []
  (let [DIM (int 32)]
    (println (q/current-frame-rate))
    (q/background 0)
    (doseq [i (range DIM)
            j (range DIM)
            k (range DIM)]
      (let [x (q/map-range i 0 DIM -200 200)
            y (q/map-range j 0 DIM -200 200)
            z (q/map-range k 0 DIM -200 200)
            r (q/map-range i 0 DIM 0 255)
            g (q/map-range j 0 DIM 0 255)
            b (q/map-range k 0 DIM 0 255)]
        (q/stroke r g b 255) ;; <- The culprit
        (q/point x y z)))))

If you replace (q/stroke r g b 255) with (.stroke (q/current-graphics) r g b 255), this code runs at 40 fps on my machine, comparable to the Java implementation.