Standard Mode (1.5.1) vs. Java Mode (2.x)?

maddy

I've been unable to compile Processing sketches in Java Mode with Processing 2.0.3 while running Mac OSX 10.8.4. Processing 1.5.1's "Standard Mode" works well, as does Processing.js on both 2.0.3 and 1.5.1, so I think my issue may lie with just Java Mode. Could someone possibly explain to me the difference between 1.5.1's Standard Mode and 2.x's Java Mode? I've had trouble finding any sort of detailed explanation. Thanks.

calsign

As far as I know, Standard and Java mode the same thing, the difference being some of the changes that were made to the language in 2.0.

Do you have trouble running any sketch? Do the examples that come with Processing work as expected? If so, can you provide the code that is broken in 2.0? We can probably spot the parts of the language that were changed...

REAS

There were some small changes between releases but the Standard mode in 1.5.1 and Java mode in 2.0.3 are equivalent; they use the same renderer. If you're using P2D or P3D in 2.0.3, that might make a difference depending on your hardware.

dimkir

As to my experience, default renderer (JAVA2D) on 1.5.1 may be up to 4 times faster than on 2 Here's link to the older forum thread: http://forum.processing.org/one/topic/wish-list-exporting-an-app-in-2-0-would-run-as-fast-as-running-a-jar-in-1-5-1#25080000002380273.html

So, my best guess is that after all "small changes" weren't that small :)

ps. This was tested on Windows (8) and with Intel Graphics Adapter with Processing 2.0.1

REAS

In 2.0, smooth() is enabled by default. In 1.5.1, smooth() must be turned on. In some programs, the difference between smooth() and noSmooth() makes a huge difference in speed.

dimkir

Thank you for clarification! The performance mystery is solved. I just did a quick performance test and tried different ways to plot 50k random points on the screen with the default renderer under Processing 2.0.2

Here're the resulting FPS:

point() with smooth() : 2 FPS (yes, two frames per second)

point() with noSmooth(): 23 FPS

pixels[] array: 60 FPS

Bottom line is: smooth() seems to slow down significantly geometric drawing operations like point() line() circle() rect(). With noSmooth() there's a descent performance. If someone needs an enourmouse amount of particles present on screen, accessing pixels array should be a good solution.

GoToLoop

@dimkir -> You've forgotten set() -> http://processing.org/reference/set_.html L-)

REAS

If the goal is to draw geometry quickly, the P2D and P3D renderers are often more appropriate.

dimkir

@GoToLoop,

Ouch! I never used set() before! Thanks for the tip.

I just tried my random point test and:

when plotting up 600 000 random points with set() it shows no notable difference in framerate to pixels[] array (meaning it still rendered at 60FPS)

When I raise amount of random points to 1 000 000, the set() starts to show that it's a bit slower than pixels[]:

set() - 38 FPS

pixels[] - 60 FPS

When I raise tha bar to 2 000 000 points, I start touching even the speed limit of pixels[] array:

set() - 20 FPS

pixels[] - 57 FPS

And 4 000 000 points, result in:

set() - 6 FPS

pixels[] - 30 FPS

So hopefully this helps people to understand better JAVA2D renderer performance.

@REAS,

I wish I could work more with P2D and P3D, however I am a "happy" owner of 3 laptops all of which have Intel Graphics Adapter. Last Processing release which worked more or lesswell with P2D was 2.0b7. With all newer Processing releases there's trouble: 8 out of 10 P3D sketches result in black/white flickering screen or run at turtle speeds. My understanding, from the commentary on the Processing repo issues page, made me believe that supporting Intel Graphics Adapter is not an option. So I humbly live in the JAVA2D world.

GoToLoop

@dimkir -> Nice you've benchmarked set() as well! ^:)^
From the results, set() is a reasonable option for folks who aren't very comfortable w/ pixel[], but needs good performance! [-O<

dimkir

It seems that for 2d purposes I will have to abandon point() completely. The good thing of set() is that it can take "out of bounds" parameters, and still don't crash. (Unlike pixels[] array, where specifying out of bound pixel coords may result on ArrayOutOfBounds Exception).

E.g.

    void setup(){
       size(800,600);
    }

    void draw(){
       set(1000,1000,0);  // this wouldn't crash
       loadPixels(); 
       pixels[1000*600+1000] = 0;   // this will crash with ArrayOutOfBounds
       updatePixels();  
    }

So, seems like set() is more comfortable to use in quick sketches.

maddy

@calsign I can run the sketch:

    void setup() {
      size(300,300);
    }
    void draw() {
      line(0,0,width,height);
    }

on 1.5.1, but when I attempt to run it with 2.0.3 the play button will turn yellow but no applet icon will appear in my dock nor will any window open.