I didn't want to add this to the bugs db because I'm still not sure if it's actually a Processing bug or not.  But I think it's worth discussing.

The issue I'm having is that whereas all of my Processing sketches seemed to work fine under Java <= 1.5, on computers with 1.6, graphical performance seems to be terrible, especially with processor intensive applets.  The thing that's really bugging me is that with 1.5, if too much computation was happening for each frame, the frame rate would just drop, and everything would still be drawn.  But with 1.6, it seems that a lot of frames are just never drawn.

Here's an example applet to check out (uses JBox2d for physics): http://www.jbox2d.org/demos/dominotower.html - it does a lot of computation, and in most cases triggers some fairly massive frame skipping with 1.6, in some cases losing five to ten frames for each one drawn.  That uses Java2d as the renderer; an example with P3D is at http://www.jbox2d.org/v2demos/ (if you hit the left arrow about four times you'll hit the same domino tower stress test), and that seems to have the same issue.  Java 5 runs slow but smooth, and Java 6 is jerky and ugly.  Same thing if I change the JVM in Eclipse, btw, and the -server flag doesn't help at all.  I'm not sure if this happens when Processing is not involved.

I originally thought this was a Windows Java 6 bug, but now that I've installed the OS X developer's preview of Java 6, I see that things are exactly the same on Mac.  I've got to assume that something has changed drastically with the way threading is handled for applets - does anyone know exactly what has gone wrong, and whether this is something that can be worked around from the Processing end or not?  The real problem is that whereas we can force a certain JVM from within Processing, on the web we're pretty much stuck with whatever people have installed, and Java 6's penetration is starting to grow substantially.  Once people hit 6uN they'll be locked on to the most recent release for good, so it's going to get harder and harder to prefer older JVMs.

Speaking of which, Ben, do you have any recent stats on JVM versions for people visiting processing.org?  I'm curious what the lay of the land is lately...

Ok, I'll file a bug on this.  It's really a shame that things like this keep getting worse as the JVM matures...I'm totally with your "cranky rant," (IMO, given the reality of the situation and the ridiculous development process at Sun it's somewhat restrained as rants go!) a lot of things seem to have gotten significantly worse since 1.4, and a lot of the wonderful things that have been promised turned out to be vaporware (escape analysis and stack allocation were supposed to "fix" all our temporary object allocation speed issues, which would help graphical performance a lot, and then it turns out they are never going to be implemented in client JVMs anyways...).

BTW, I think the low percentage of 1.6 Mac users is due to the fact that even on Macs with 1.6 installed, the 1.6 JVM is disabled unless you're using a 64-bit browser.  I think most people are using 32-bit browsers (pretty sure Safari is one of those), so that would explain it.  Come to think of it, I'm not sure if there are any 64-bit browsers currently available for OS X without compiling them yourself, so I'm not even sure where those two 1.6 OS X users came from...

I'm actually a little bit shocked that so many people are running 1.6.  In any case, I'm totally with you on not officially supporting it; that said, if I get a chance I'll see if I can determine if this is actually a problem with 1.6 or whether it is a bad interaction between that and Processing, because if it's Sun's bug, it should be reported there instead (not that they'll care, as little things like user experience and non-J2EE performance problems never seem to matter much to Sun...okay, that's all the Sun-bashing I'll do for this post, I promise!).  Otherwise, maybe there's some change that could help within Processing without messing up the software on older VMs.