9
edits
Changes
no edit summary
=SIGGRAPH 2010=
==community and collaboration==
Society has a vital interest in encouraging and rewarding innovation. Presently, there are two major models characterizing how this may be done. The first, the “private investment” model and the second, the “collective action” model (von Hippel and von Krogh 2003). Von Hippel and von Krogh go on to say that the private investment model assumes private returns to the innovator resulting from private goods and efficient rule of intellectual property protection. Whereas the collective action model assumes collaboration from multiple innovators resulting in a public good that can be accessed by anyone.
The phenomenon of open source software development illustrates that in order to solve a shared or personal technical problem, users program and reveal their innovations without getting private returns from selling the software. The source code of open source software is made freely available so that users can access, modify, and redistribute it (Shuo July 2010). Open source projects are released under the terms and requirements of certain licenses.
The processingjs project was started by one individual who wanted to utilize the HTML5 canvas element and take advantage of the Java Processing language. It took about seven months to get a working version, consisting of 5000 lines of code, of the project released. However, the part of the project that allowed for dynamic conversion of code written in the Processing language, to JavaScript, referred to as the parser, was limiting. Moreover, the release contained a lot of gaps as some of the functionality was not yet supported (Resig 2008).
The project, similarly to other open source products, was released with the hope that a developer community will converge around it and contribute to development. The Mozilla experience however, suggests that proprietary products may not be well-suited to distributed development if they have tightly-coupled architectures. There is a need to create an “architecture for participation,” one that promotes ease of understanding by limiting module size, and ease of contribution (MacCormack, Rusnak and Baldwin 2004). In order to facilitate an architecture for participation a number of things needed to happen. First and foremost the source code must be readily available. Secondly, the inner workings of the project and the missing functionality must be publicized and a dialog started.
A Git repository was started to allow contributors and users easy access to the project’s source code. Git is an extremely fast, efficient, distributed version control system ideal for the collaborative development of software. The repository is hosted by GitHub which provides an online way of collaborating with others and forking repositories (GitHub Social Coding 2010). GitHub makes Open Source’s fork-and-extend legal capability a practical reality (Walsh 2009). This promotes a pressure free environment where any contributor can alter the code of their own repository without worrying about their coding style or syntax.
To raise awareness and encourage dialog both a project website and an online discussion channel were made. The website consisted of tutorials that allowed novice users to quickly pick-up the project, demonstrations of previous Java Processing examples that were ported to processingjs, and a list of features that were not yet supported. Furthermore an Internet Relay Chat (IRC) channel was made to allow for general discussions on the project as well as a Google Group which would facilitate discussions for those unfamiliar with IRC.
The project grew and attracted numerous contributors. However, as Behlendorf (1999) stated, “essential to the health of an open-source project is that the project have sufficient momentum to be able to evolve and respond to new challenges. Nothing is static in the software world, and each major component requires maintenance and new enhancements continually”. To support the growth of the project Lighthouse, an online issue tracking system was put in place. Lighthouse allows anyone to create tickets related to the project. A ticket may have many purposes including reporting a bug in the current code, requesting a new feature, or simply starting a discussion. A major advantage to using Lighthouse is the ability to plan milestones and allow users to see which features and bugs fixes will be available in the next release. Not to mention the tracking of discussions that have already happen that novice users and new contributors can learn from. Of course an issue tracking system is not all the project needed to succeed. In September of 2009 ten students from Canada’s Seneca College joined the project with the hopes of releasing a 1.0 version – the projects first stable release. The introduction of new contributors was vital to the health of the project. As identified by Liu et al (2010), a high turn-over rate of developers is common in an Open Source project but it also proves to be very challenging. With a dedicated team that included a release engineer it became possible to have frequent releases of the project and an up-to-date project repository. However, it also brought to life another well known problem often found in Open Source projects; bad code quality.
A 2008 study done by Koch and Neumann that analyzed the impact on quality and design associated with the number of contributors and the amount of their work yielded the following conclusion. “We identify the number of commits, the number of distinct programmers, and the active time as factors of influence which have a negative effect on quality. In particular, complexity and size are negatively influenced by these process metrics. Furthermore a high concentration of added work fosters bad quality.” To ensure that all code patches meat the coding standards, and passed various tests a two step review process was put in place. The first step was a peer-review that can be performed by virtually anyone but was usually performed by another contributor. The second step was a super-review that was performed by only the contributors that had the appropriate status. In order to be able to perform super-reviews a contributor must have a combination of the following, advanced JavaScript knowledge, thorough knowledge of the project and its components, or the ability to identify potential problems. In addition to this process each release was thoroughly tested on all platforms and all supporting browsers.
In December of 2010 the first stable version of processingjs was released. Included in the release were over 1,000 bug fixes, features, and under-the-hood improvements. At the time the project had twenty six recorded code contributors, eleven of which had the status of super reviewer. At least twenty users logged in to the IRC channel at any given time, 608 members of the Google Group and 99 forks of its repository.
Scalable Vector Graphic Support
Processingjs supports two major systems for representing graphics: raster, and vector graphics. Raster graphics are images represented by an array of pixels. Each pixel is either an RBG value or an index into a list of colors. This series of pixels, or bitmaps, is often stored in a compressed format such as JPEG, GIF, and PNG. Vector graphics however are objects rather than a series of pixels. They work by describing the grid points at which lines or curves are to be drawn. Some people describe vector graphics as a set of instructions for a drawing, while bitmap graphics (raster) are points of color in specific places (Eisenberg 2002). Vector graphics have a significant advantage over raster graphics because they are scalable; they can be scaled to any size without the loss of image quality. SVG, which stands for Scalable Vector Graphics, is a language which describes 2D graphics (straight lines or curves) expressed in mathematic relations in XML. Processingjs supports basic SVG shapes, path parsing, transformations and style, as well as shape reusability.
Basic SVG shapes include line, circle, ellipse, rectangle, polygon and polyline. As mentioned above the SVG language will provide instructions on drawing each shape. The attributes of the circle include center x-coordinate, center y-coordinate, and the radius. The x and y coordinate of 0 represents the upper left corner of the picture. The y coordinates increase as you move vertically downwards; and the x coordinates increase as you move horizontally to the right.
Paths represent the outline of a shape which can be filled, stroked, used as a clipping path, or any combination of the three. A path is described using the concept of a current point. In an analogy with drawing on paper, the current point can be thought of as the location of the pen. The position of the pen can be changed, and the outline of a shape (open or closed) can be traced by dragging the pen in either straight lines or curves. Paths represent the geometry of the outline of an object, defined in terms of moveto (set a new current point), lineto (draw a straight line), curveto (draw a curve using a cubic Bézier), arc (elliptical or circular arc) and closepath (close the current shape by drawing a line to the last moveto) elements. Compound paths (i.e., a path with multiple subpaths) are possible to allow effects such as "donut holes" in objects (Paths 2010). Table 1.1 illustrates the different commands represented inside a path. Uppercase commands use absolute coordinates and lowercase commands use relative coordinates.
Path commands
Command Arguments Effect
Command Arguments Effect
Command Arguments Effect
M, m
x y
Move to given coordinates.
L, l
x y
Draw a line to the given
H, h
x
Draw a horizontal line to the given x-coordinate.
V, v
y
Draw a vertical line to the given x-coordinate.
A, a
rx ry
x-axis-rotation
large-arc sweep
Draw an elliptical arc from the current point to (x, y). The points are on an ellipse with x-radius rx and y-radius ry. The ellipse is rotated x-axis-rotation degrees. If the arc is less than 180 degrees, large-arc is zero; if greater than 180 degrees, large-arc is one. If the arc is to be drawn in the positive direction, sweep is one; otherwise it is zero.
Q, q
x1 y1 x y
Draw a quadratic Bézier curve from the current point to (x, y) using control point (x1, y1).
T, t
x y
Draw a quadratic Bézier curve from the current point to (x, y). The control point will be the reflection of the previous Q command's control point. If there is no previous curve, the current point will be used as the control point.
C, c
x1 y1 x2 y2 x y
Draw a cubic Bézier curve from the current point to (x, y) using control point (x1, y1) as the control point for the beginning of the curve and (x2, y2) as the control point for the endpoint of the curve.
S, s
x2 y2 x y
Draw a cubic Bézier curve from the current point to (x, y), using (x2, y2) as the control point for this new endpoint. The first control point will be the reflection of the previous C command's ending control point. If there is no previous curve, the current point will be used as the first control point.
Table 1.1 Source: (Eisenberg 2002)
Transformations and styles can be applied to all elements in the SVG language. In order to change the placing of a particular shape a transformation can be applied. Moreover, to change a shape’s look a style attribute can be applied. Processingjs supports six transformations: matrix, translate, scale, rotate, skewX, and skewY. A matrix transformation specifies a transformation in the form of a transformation matrix of six values. Translate moves the shape to the x and y values provided. Scale increases or decreases the size of the shape. The rotate transformation rotates the shape either by its coordinates. You may supply multipleorigin or by a specific point. SkewX skews all x-coordinates by a specified angle. Visually, this makes vertical lines appear at an angle. Lastly, skewY skews all y-coordinates by a specified angle. This makes horizontal lines appear to be at an angle. One can apply multiple transformations to any shape. Styles that can be applied include opacity, fill, fill opacity, stroke, stroke weight, and stroke opacity.
Processingjs’ class structure enables shape reusability. Each shape or group of shapes has its own properties and can be recreated without the underlining SVG language.
Bibliography
Eisenberg, David J. SVG essentials. O'Reilly & Associates, Inc. Sebastopol, 2002.
"Paths." SVG 1.1 (Second Edition). June 22 , 2010. http://www.w3.org/TR/SVG/paths.html#Introduction (accessed Dec 2010).
==DOM integration==
What is this?
Merging technologies
Processing.js helps merge multiple new and emerging HTML5 technologies together to make design and production for the web easier. Processing.js connects the processing language with web technologies such as WebGL, JavaScript, and the HTML5 canvas element. More importantly the library is built in such a way as to allow new technologies to be added in at a later date and for the scope of the library to change as new technologies evolve. In the future, other technologies such as 3D audio, controller inputs, and HTML5 video integration could be added to the library to allow Processing sketches to integrate with them.
-WebGL integration example paragraph-
Image manipulation
Processing.js includes full support for pixel and color manipulation of images on the canvas element. Images can be resized, tinted, blended, copied, resized, or have filters and masks applied to them. Images can also be manipulated at the pixel level allowing for any level of image manipulation required. Images can also be created and filled from pieces of other images, the current canvas content, or have their pixels filled dynamically. This functionality allows for images to be created from external data that is passed into the processing sketch and visualized through code.
copying pieces of an image
blending regions of an image with different modes
different types of filters applied to an image
resizing an image
Pjs directives
In order for Processing.js to closely match the functionality of the native Processing language some custom flags had to be created to make the library behave like the native language. Pjs directives are a set of commands that are embedded in a multiline comment at the top of the sketch to control a few aspects of how the sketch will work. Placing the directives in a multiline comment allows for backwards compatibility of sketches with native Processing so that sketches written in Processing.js can be run on the native Processing JAVA platform. There are currently three Processing.js directives. These directives add the ability to preload images before the sketch begins to run, and to toggle transparent backgrounds and anti-aliasing of lines.
==WebGL section==
