9
edits
Changes
no edit summary
==Introduction==
Game delivery in a webpage typically requires some sort of browser plug-in. However due to security concerns and general wariness to pluginsof plug-ins, they are not the most effective means to deliver content. Furthermore there are often some platforms where a plugin plug-in does not exist or cannot exist , such as in the mobile environment. Even Flash , which is one of the most ubiquitous visual environments , is not available on every platform. The only real solution to web delivery of rich graphics is to integrate it into native browser technology.
The HTML <canvas> element allows the programmatic delivery of graphics in a web page without plugins. With its inclusion in the soon to be released IE 9, the <canvas> element now represents a means to deliver graphical content in all the major browsers. The typical way to interact with the canvas is to use JavaScript. However for artists, educators, and other people less familiar with JavaScript, learning to do this can be a barrier to entry.
The Processing language introduced by Ben Fry and Casey Reas is a simple and elegant language for data visualization that is already used by artists, educators as well as commercial media to deliver rich graphical content called sketches. There is a large body of work around the world which is being developed using Processing. However, Processing was originally developed with in Java and thus delivering Processing sketches on a webpage required that the user install a Java plugin. Furthermore the sketches themselves are self contained items as opposed to being part of a web page. That is, the elements of the Document Object Model (DOM) of a webpage can not interact with it or vice versa. Thus, while it is possible to deliver visual content it would be difficult to create Processing sketches to take full advantage of modern web services such as flickr, twitter etc.
Processing.js is an open source, cross browser JavaScript port of the Processing language. It uses the canvas element for rendering and does not require any plug-ins. However, Processing.js is more than just a Processing parser written in JavaScript. It also enables the embedding of other web technologies into Processing sketches. This extension will allow for a new set of visualizations previously not possible. Processing.js seamlessly integrates web technologies with the processing language to provide an accessible framework for multimedia web applications.
==JavaScript==
When the original Processing Language, also known as P5, was first developed , Java was suppose supposed to become the language of the web while JavaScript was a little toy client-side scripting language that many did not take seriousfor small tasks. However, as As the web matured, JavaScript , however, became the language of the web but , although many of the misconceptions about it still persistspersist. /*cite javascript the good parts here*/ With recent developments in JavaScript technology, JavaScript is now fast enough to handle the demands of realtime interactive web graphics.
Processing.js is more than just a Processing parser re-written in JavaScript. It is designed in a way that connects the Processing language (also known as P5) with web technologies such as JavaScript, the HTML5 canvas element, JQuery, and various web services. /*Awkward*/ Furthermore, Processing.js is built in such a way as to allow easy integration of new technologies as they emerge. It is designed to be fast and to take advantage of recent JavaScript developments to ensure that the platform is responsive.
While syntactically JavaScript and Java are fairly similarsyntactically, there are some fundamental differences that has made this conversion challenging. The first is that we wanted to do this conversion dynamically in real time. The code produced by the converter ??? needed to be fully object oriented and we had to provide support to all native Java functions and objects that are supported by Processing. We also had to take into account the differences between working with web resources vs local resources. Furthermore we had to consider how we would handle some fundamental differences between Java and JavaScript such as typed vs. typeless variables, function overloading and variable name overloading.
The original code for Processing.js used regular expressions to convert Java into JavaScript when it was encountered. It did this by scanning for hints of Java code within the entire sketch and then replaced the Java code with its JavaScript equivalent. Due to the difference in how Java and JavaScript accessed object properties from methods inside an object, the with statement was used as a simple solution to avoid having to prepend all function calls with "this." or "Processing.". However, the use of the with statement also meant that the JavaScript generated would fall off Trace /*cite trace paper here... do we need to talk about trace in the back ground section???*/ making the code run slower than it needed to in some browsers. Later this method of scanning the entire sketch was replaced by the creation of an abstract syntax tree that broke up the code into smaller pieces. Each piece then had the regular expressions applied to change it. This made it was easier to apply the regular expressions correctly without accidentally converting code that was already working. It also made it easier to create proper inheritance structures and attach properties and methods to the correct object in the hierarchy chain as smaller pieces of code was being converted at any one time.