which version of processing?

and why mention opengl in the subject when you don't use it in the code?

and why are you using an offscreen buffer rather than drawing the squares directly? this way you set all the pixels twice - once for the draw, once for the copy.

setting pixels directly also faster than rect(), but more work / maths.

also, try frameRate(25) in setup...

I'm using Processing 2.0. I've seen some examples where people use lower level OpenGL calls to do more complex things (for example: 1,000,000 points in OpenGL using Vertex Arrays), so I figured that's the direction I'd need to move toward.

I thought PGraphics could be used to save time by only drawing the completed buffer once, but after testing I suppose this isn't true, since removing the PGraphics and just using rect() runs at about the same speed.

The pixels array does seem like a fast alternative, but can you think of a scheme that would index them in the same way as above? I feel like the number of comparisons might compromise that. Also, I'd like to keep 60 FPS if I can.

Your code recolors over 90.000 shapes on every frame. Even if you switched to retained PShapes the recoloring would be a bottleneck, because it's a CPU-GPU operation.

The code example below gets the same visual result, but at 60 fps. Press the mouse to pause the recoloring.

Code Example (Processing 2.01)

1. int scale = 5;
2. PImage grid;
3.  
4. void setup() {
5.   size(displayWidth, displayHeight, P2D);
6.   grid = createImage(width/scale, height/scale, RGB);
7.   ((PGraphicsOpenGL)g).textureSampling(2);
8. }
9.  
10. void draw() {
11.   if (!mousePressed) {
12.     grid.loadPixels();
13.     for (int i=0; i<grid.pixels.length; i++) { grid.pixels[i] = color(r(), r(), r()); }
14.     grid.updatePixels();
15.   }
16.   image(grid, 0, 0, width, height);
17.   frame.setTitle(int(frameRate)+"");
18. }
19. 
    
20. float r() { return random(255); }
    

was another thread that had someone trying this static noise thing and, iirc, dave replaced the random() call with his own lcg as a speed improvement.

here:
https://forum.processing.org/topic/why-does-this-simple-program-run-at-such-a-low-framerate

amnon.owed's example seems perfect, at least for me: runs just as fast with a quarter of the CPU time. Never thought to resize a PImage to accomplish the effect because I thought I'd lose quality, but I see that the texture sampling handles that.

And I'll look definitely into the examples in the other thread for better ways to randomize color.

Thanks all!

Updated the post. Code example is explicitly for 2.0x since it won't even run in 1.5.1.

Indeed the color randomization can be optimised.

Instead of 3 multiplications you can also use: (int)random(-16776723);