Why are you using a framerate of 2000?

It causes an NPE on the GL2 object here. I found that if you do gl = pgl.beginPGL().gl.getGL2(); again on draw when switching frameRate it works.

I usually include it with "gl.setSwapInterval(0);" to unsync it.  I do this to test the performance, so that I can more efficiently render more stuff.

rbrauer, ya, that's what I'm getting as well.

No crash on Windows 7 x64 + Processing 2.0b7 x64 + NVIDIA GTX 570M.

When I press the key for the first time, I see an almost unnoticeable flicker. The frameRate before and after key press remains 60 fps (so perhaps it's capped by some setting elsewhere on my computer).

Should have mentioned that my testing was on a Mac OSX 10.8.2

I have the impression that JOGL started to cap the framerate at 60fps at some point recently, because a while ago you could set higher values with the frameRate() function and Processing would try to render at that rate.

Andres, I almost wonder if it's 30fps.  It reports faster than 30fps, and I can get it to report faster than 60fps, but I can tell that it is not - it's not smooth at all.  My primary sketch is jumpy, even though it reports 60fps (or more when I unsync).  Hovering over controlP5 buttons gives a delayed response.

I've ran a profiler on it and most of the time (a good 50%) is spent in the gl.Flush().

The sampler breaks down another 50% spend on Thread.sleep(), which is directly in the  PApplet.run().  I'm not sure why it would delay that because it's running (or so it claims) at around 60fps.  Removing that bit of code in PApplet, doesn't appear to improve the performance any.  So it expect it's something else.. I have no idea what though... it's dragging.

Ok, thanks for the feedback. I don't know what could be the cause of the sluggish animation you are observing. I will take a look at this. Let me know of anything else you find out by profiling and testing.

I'm seeing a larger problem with regard to the crash reported here.  If you have a similar sketch and do a resize, it crashes as well.  They seem to be fixed by resetting the gl in the draw.

1.   gl =  pgl.beginPGL().gl.getGL2();

If that were the case and it was the rendering of points, I would expect to see the same jerkiness in Processing 1.x since it would be a GPU bottleneck, but I don't.  It runs perfectly fine in prior versions. 

I'm not sure how much needs to go on, as it's not rendering a circle point, but a sprite tied to a vertex.  I even turn off the smoothing, so its just a square sprite.  I would think processing triple the vertex count, triple the color buffer (not applicable in this example I think), along with billboard rotation would cost more than adjusting the point size.  At least, in my prior tests when comparing textured quads to point sprites, the sprites were way faster.

I removed the point size in the shader and it didn't make it any faster that I could tell.. It was still jerky.  Commenting out the section you mentioned (which is in there twice) would seem to defeat the entire sketch, as that is what renders the 60,000 textures.  Otherwise, you're just rending a skybox.  I still don't see how it would be a GPU bottleneck if it works perfectly fine in 1.5 using the exact same shader and opengl code.

ok, not sure at this point what could be the reason... I will look at it a bit more and let you know what I find.

Thanks, also note the inconsistency with what is reported for framerate vs visual.  It reports 60fps for me, but 60fps should be very smooth.  So why is it jerky if it is running at 60fps?  It seems the processing of each frame is fast, but maybe what is displayed / rendered is not properly "in-sync" or something.  I'm not seeing any tearing, but perhaps there is a delay or out-of-sync between the frame rate and when flush is ready / loaded.  ??