Best Pratice Guidelines
Writing Valid Code
It is always a good idea to make sure your Processing.js code runs as a native Processing application. This helps for two reasons: 1) People using the native application will be able to use your code. 2) You may discover a function that needs fixing, or does not exist. In which case, you will be able to inform Processing.js developers where additional work is needed.
It is possible to save time by building your visualization in the Native Processing application first; however this is not always appropriate as your script may be integrated with elements in your HTML document. Even so: using the native application to get a feel for the language is helpful.
Once you have validated your script runs natively, you may want to add a quick comment at the top of your source, such as: /* Native Processing Compatible */
Sloppy Parsing
Processing.js uses a "Sloppy" parser, meaning that when your code is executed, it does not attempt to debug your code. The great thing about this is you can mix native Processing code with Javascript. For example, if you have jQuery loaded into your page, you could output some of your variables to a <div> using a jQuery selector.
void mouseMoved(){
$("div.output").text(mouseX);
}
Common Mistakes
Because Processing.js can mix languages, writing your script outside of the native Processing application will leave validity errors un-detected. Fortunately these mistakes are easily fixed. Here are a few of the most common problems and their solutions:
- Setting an invalid type. Example:
int x = 100.1;
will work in Processing.js because it's valid Javascript; but in native Processing you will have to remove the decimal:int x = 100;
or use a floatfloat x = 100.1;
. - Using a Javascript methods. Example:
y = Math.sin(frameCount);
. If you are in the habit of writing lots of Javascript, you may find yourself accidentally using JS methods. Because the parser is sloppy you may not notice until you try and run the code as a native Processing visualization. The correct syntax is:y = sin(frameCount);
. - Array Access. In Processing.js you may find yourself defining a multi-dimensional array the Javascript way:
var myLines = [ [x1,y1,x2,y2], [x1,y1,x2,y2] ];
In Processing.js you should define your array like this:int[][] myLines = { {x1,y1,x2,y2}, {x1,y1,x2,y2} };
Of course, all of these are suggestions. You can use Javascript as much as you like, but it is good be aware of the difficulty others may have when trying to run your code as a desktop application.
Setting the Framerate
If you want your visualization to move at the same speed regardless of the machine at which it is viewed, you will need to set the frame rate. Failing to set the frame rate causes Processing to render the frames as fast as it can process them. This is great if you are creating a visualization to demonstrate the speed of one machine compared to another or are targeting specific hardware.
But leaving the frame rate unset is not such a good idea when your script relies upon input from the mouse and keyboard. This is because the user-experience will differ greatly between machines with varying rendering speeds.
void setup(){
size(200,200);
frameRate(20);
}
The frequency of the frame rate is measured in frames per second. Television usually runs between 25 to 30 frames per second, (depending on which part of the world you live in). A computer with a decent graphics card will attempt to run modern games at 60fps. But web video can range from as low as 10fps all the way up to regular television speeds.
Choosing the ideal frame rate for your visualization is going to be a process of trial and error. Here are some factors to consider when choosing your frame rate:
- Applying strokes to complex paths
- The size() of your canvas
- The size of your arrays
- Heavy use of alpha channels
