frame rate decreases drastically w/ very large stage sizes in P2D and P3D

[processing-bugs]

Original author: jer.blp...@gmail.com (April 07, 2012 16:00:38)

Blank sketches run at very low frame-rate with large stage sizes.

What steps will reproduce the problem?

1. Open a new sketch
2. Set the sketch size to something big (ie. 4000x2000)
3. Run the sketch

void setup() {
size(4100,2100, OPENGL);
}

void draw() {
background(0);
fill(255);
text(frameRate, 50, 50);
}

I am on a 1.8GhZ MBA w/ 4GB RAM, running 10.7.3.

I definitely think this issue is hardware-dependent, as it seems to behave a lot better with faster graphics cards. Still, a blank stage shouldn't cause this much of a slow-down? (It doesn't in 1.5.1)

Original issue: http://code.google.com/p/processing/issues/detail?id=1051

[processing-bugs]

From f...@processing.org on August 21, 2012 13:43:27
Chances are, this is the card switching over to doing the rendering in software since it can't fit on the GPU. So all the work is going back and forth between regular memory and the card, which is very slow, even with nothing being drawn. (Sort of related to how things run slowly in Java2D even when there's nothing being drawn.)

[processing-bugs]

From andres.c...@gmail.com on August 21, 2012 15:01:27
I run some tests using a slightly lower res (3072x2048) with the test code suggested by Jer. On a macbook Pro with a discrete Radeon HD 6490M and OSX 10.7.4, the OPENGL renderer in 1.5.1 doesn't show any slowdown, and frameRate stays at ~60. When running the sketch with 2.0a8 and the P3D renderer, the framerate reduces to around 16. JAVA2D is faster at 34 or so.

OpenGL texture size limit is 4096x4096, so I'd say that the lacking of space in GPU memory is probably not the reason for the slowdown, at least in this case, which is also supported by the fact that OPENGL in 1.5.1 doesn't run slower. Furthermore, I run the same sketch on a PC desktop machine with a Geforce 580GTX card, using Windows 7 64bit and Ubuntu 12.04 64bit, and there was no slowdown in 2.0a8 under both OSes.

[processing-bugs]

From r...@processing.org on August 21, 2012 16:04:07
I confirm the same results as Andres this morning running Jer's examples on 10.6.8 w/ NVIDIA GeForce GT 330M on a MBP.

[processing-bugs]

From andres.c...@gmail.com on August 22, 2012 15:39:14
As an additional note, disabling smoothing makes things run a bit faster (~30 fps at 3072x2048, on the mbp with Radeon HD 6490M and OSX 10.7.4)

[processing-bugs]

From f...@processing.org on November 25, 2012 01:52:29
I don't think this is something that can really be fixed... I'm all but certain that it's hitting hardware (or driver) constraints of the graphics card. So it's going to behave differently across platforms, smoothing settings, driver versions, etc. Probably best we can do is make a note of it on the Wiki for OpenGL.

[codeanticode]

I just pushed the first version of the GWL library (working name) that bypasses Processing's AWT frame and renders directly into a native window created with NEWT.

b8f4e75

Still very rough around the edges, but I think it solves the basic problem described in this issue. I just tested it with a resolution of 2560x1440, which under OSX and the core OpenGL renderer stutters significantly, and it runs very smoothly at 180fps. @REAS, @benfry, please let me know what you think about this.

[benfry]

As discussed, I think it's the correct route. I suppose we can include it in the distribution for now, or we can just have it install easily via the contrib manager from download.processing.org. But I think the footprint is small enough that we're probably fine w/ including it.

[REAS]

@codeanticode At the moment, how do we test it?

[codeanticode]

Hi Casey, first you need to build it manually, by changing to the java/libraries/glw folder and running ant build. Then, build and run processing and you should see it under Examples/libraries/glw.

[codeanticode]

I did some more work on the GLW library, it's looking pretty good, specially for high-res sketches. @benfry, @REAS we should discuss at some point about the correct way of creating the window (passing options, etc).