9
edits
Changes
→First Draft
While syntactically JavaScript and Java are fairly similar, 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 JavaScriptequivalent. 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. ==Browser Unification== One important feature provided by Processing.js is that it hides the differences between browsers. Web standards are often loosely defined, and thus variations can exist. These variations not only exist between different browser vendors but can even exist between versions of the same browser on different platforms. Something as simple as key events can vary widely between browsers. Processing.js hides a large number of these differences from the user by creating a unified method of handling events. Regardless of the browser/platform, the functions for handling events within Processing.js are handled the same way. Different browser makers are also at various stages of implementation for various newer technologies. For example, WebGL provides typed arrays which are much faster than traditional JavaScript arrays. While these typed arrays are implemented for WebGL, they can be used outside of that context also and can provide tremendous speed improvement. However, not every browser supports WebGL at this time thus a fallback to regular JavaScript arrays is necessary if the feature does not exist. By hiding these differences between browser makers from the user, Processing.js provides a means for game developers to make games without worry about the differences between browsers. If a feature exists that can make the rendering smoother and faster, Processing.js will make use of it to increase performance. If it does not exist a fallback mechanism is available to allow it to still run.
==3D support==
The introduction of the <canvas> tag into the HTML5 specification allowed Processing to be ported to JavaScript, thus enabling users to run 2D sketches within the browser without additional plug-ins. At the time when porting began, there was no plug-in free method of delivering 3D content. This limited Processing.js to its 2D functions. WebGL, A JavaScript API that is based on OpenGL ES 2.0, is now being implemented by Firefox, Chrome and Safari. It is now has become a viable candidate for use in Processing.js to render 3D sketches. Additionally, since WebGL closely matches OpenGL which is used by Processing, it substantially aided the porting processof the 3D Processing functions was relatively straight forward.
===Differencesbetween OpenGL and WebGL===The matter of porting Processing (which uses OpenGL/*1.x?? if it was opengl 2.0 it would have been even easier right?*/) was simplified because the WebGL interface is similar that of OpenGL, but there are a number of differences between the interfaces. Arguably, the The single largest difference between WebGL and OpenGL 1.x is that like OpenGL ES 2.0, the fixed-function pipeline was been removed. Because of this, not all Processing source code could not be ported directly. Instead, user-defined vertex and fragment shaders were necessary to write for lighting operations. Since some shapes in Processing aren't lit and others were, multiple shaders were written. One shader exists for lit objects such as boxes and spheres, another less complex shader was written for unlit objects such as lines and points.
The following shaders are used for rendering unlit shapes specified with begin/end function calls.
"}";
</pre>
===Typed Arrays===
[http://weblog.bocoup.com/javascript-typed-arrays link]
Because typed arrays are only available for pre-release browsers, they cannot currently be used in 2D sketches. Once they become implemented in browsers, a significant amount of the Processing.js code base can make use of these structures, increasing performance throughout the library. ===Specification Changes and Browser Inconsistencies===As the specification is concurrently implemented in different browsers, several inconsistencies between browsers have appeared. These range from minor issues, such as Minefield and Chrome/Chromium return "function" while WebKit returns "object" when the type of a typed array is queried. Another is the way WebGL's readPixels() function is implemented. This function isn't used extensively in the library itself/* andor, but it is used mike said its in the Processing.js reference testing framework. ===Problems===WebGL provides a close match to OpenGL for incorporating 3D into Processing.js, but it does present some issues when trying to port over code. There are interface differences, changes to the interface are common, and some functionality isn't available at all such as point smoothing. ==Browser Unification== One important feature provided by Processing.js is that it hides the differences between browsers. Web standards are often loosely defined, and thus variations can exist. These variations not only exist between different browser vendors but can even exist between versions of the same browser on different platforms. Something as simple as key events can vary widely between browsers. Processing.js hides all these intricacies from the user keeping it simple for content creators. ???*/
==Conclusion==
==References==
=Notes=
