I've been having trouble with framerate(). If the CPU load drops
dramatically, the framerate will oscillate, first making the sketch way too
fast for a little while before settling down closer to the target fps. I
took a look in PApplet, and sure enough there's a damper used inside
display() to interpolate between framerates.

Right now it looks like this:

framerate = (framerate * 0.9f) + ((1.0f / (elapsed / 1000.0f)) * 0.1f);

this makes sense for most semi-steady execution situations, but causes the
sketch to accelerate and then decelerate if the load decreases sharply.
this constitutes a visual hiccup, critical in some situations where a
target audience might experience it as a bug.

my solution was to change the weight of the damper system to something like
this:

framerate = (framerate * 0.2f) + ((1.0f / (elapsed / 1000.0f)) * 0.8f);


I have posted a work-around on Processinghacks:
http://www.processinghacks.com/hacks/framerate

tom carden adds:

Is the old hint/unhint mechanism still supported for anything -
hint(NO_FRAMERATE_DAMPER) or something might do the trick?

the hint mechanism would probably be the proper route if it's something that's an issue for
others. or if it's not a 90% vs 10% thing then it may just need to be fixed or properly
calibrated. it's not something i've given a lot of time to.

there are some other issues with framerate, where the resolution of the clocks can cause
problems (1000 ms / 30 fps -> ~33 ms) so i have a feeling that might be the cause for the 2x
slowdown that sometimes happens with java2d. (but that's another bug, i think it's filed
somewhere else in here)

This should be fixed in release 0145 (now in SVN), which uses a more
accurate threading and timing mechanism based on System.nanoTime().