In JAVA2D, the point() function slows the code down significantly. This
happened somewhere between 148 and 152.

The following code demonstrates the problem, comment and uncomment the line
with point() to see the difference.

void setup() {
size(600, 600);
}

void draw() {
for (int i=0; i < 50; i++) {
ellipse(random(width), random(height), 50, 50);
point(random(width), random(height));
}
println(frameRate);
}

Is it just as slow with set()? And to verify, this is on the Mac?

set() is just as slow, i haven't tested on Win or Linux.

So I changed point() to use set() when it's only one pixel, to deal with
inconsistencies in some renderers not drawing the point otherwise (e.g.
points were sometimes not drawn at all). On Windows it's been faster to use
set() than point() anyways, but apparently that's not the case on OS X. Hrm.

I was extremely surprised by the the difference, though. In this particular
example, it's the difference between 60fps and around 2fps.

It seems to be cause not by an inherent slowness in point(), but by rapidly
switching between drawing points and ellipses.

If you don't draw ellipses in the loop, then it runs fine, and if you take
the points out into a different loop (i.e., draw 50 ellipses, then draw 50
points), it runs significantly faster.

As I don't know how to profile it with Shark (Processing applets don't show
up), I'm not sure exactly where it's getting stuck when this happens.

Another peculiar thing is if I export it as a web applet and run it in a
browser, this slowdown doesn't occur, which suggests to me that it's more
of a problem with the Java VM that's being used when it's run as an
application.

This is specific to the default (JAVA2D) renderer.

The problem does not exist on Windows.

It also does not exist on OS X if you turn off Apple's Quartz renderer. We
set useQuartz to true inside PApplet.main() because otherwise most other
rendering is terribly slow on OS X. (See the discourse for complaints about
releases in the 0140s being really slow on OS X.)

It appears to be a problem with WritableRaster.setDataElements(), where
Apple must be using some kind of optimization to shuttle pixels to/from the
graphics card. That's why it's fine if point() and ellipse() are used
separately.

For the time being, I think we'll make a note in the point() and set()
reference that under some circumstances point() and set() are really slow.
Eventually we'll just have to remove the useQuartz stuff, even if it makes
all the OS X rendering 20-50% slower.

(Also thanks to dlp for the point/ellipse clue.)

fixed for 1.0.4, either due to the recent Java update, or other changes to
the point() code.