Generative art and Processing

Generative art can make presentations look more beautiful without worrying about copyrights. It can also be printed on a large canvas and put in an art gallery if needed. But despite of this, its place is still not on the web as it has no function, it fulfills no task and it doesn't support a greater meaning. We can't make our images too big on the web; the quality of the ones we include is decreased by compression, so that our original may no longer look the same, especially when we remember how big uncompressed files can be and what fraction of these bytes we see on the web. If images are frequently one of the heaviest elements on a website, it makes sense to use the least amount of them that will support our current goal.

We could create beautiful things with the triple (HTML, CSS, Javascript), but the browser can't support an infinite amount of DOM nodes, CSS can't do some more complex animation that requires synchronization in the movements of various elements, and drawing on the <canvas> through JavaScript requires so many function calls, that it becomes too slow to be practical with many objects. On my machine I can render approx. 20000 DOM nodes and draw 50000 rectangles on the canvas before the browser becomes unresponsive. Contrast this with the problems we have today, which can have millions of instances of input data for which we seek an answer. This means that any problem of moderate complexity can't be solved on the web as there will be no way to represent its instances through the existing technologies.

Processing, another tool for generative art, takes a different approach. It already feels a cohesive whole and we don't need to combine different technologies together to make it work. Since it is based on Java, we can draw up to a million distinctive elements in reasonable time. It is suitable both for animation (as this free book shows) and for still images (just call noLoop() inside draw()). With Processing we can quickly explore how the various variables change over time and how their relationships work—in a very visible way. Most frequently used functions are directly accessible and they don't require an object instance to be called. This can save a lot of time. Instead of typing ctx.fillRect(), we type only rect(); instead of Math.min() or Math.sin(), we just type min() and sin(). Although this is possible in JavaScript, we would need to define a reference to each function. Mathematical formulas are often needed in various simulations and being able to use them conveniently is very important.

After we start Processing we see a window with only few options, which makes it especially easy to use. The default font of the editor is a bit small, but we can change it from the configuration file. Not knowing this has forced me to abandon Processing the first time I used it, because I felt that the editor was too limited to not even offer such an option. We need to test which fonts will render well on our system, because some of them may be blurred or not show in full height. Consolas seemed to work well for me on Windows. Pressing Ctrl+R executes the current file and draws the sketch in a separate window. Although convenient, this shortcut may be overlooked, but it is important to understand that it serves double purpose: after the initial run it closes the existing window automatically and then reopens it with the new drawing when pressed again. We don't need to manually click the close button of the window or the stop button in the editor. It would be even better if the graphics window remained open to redraw the new image. But even so the cycle time between code changes and visible output is quite small.

Processing.js has a similar API, but works in the browser. The library is relatively big, so it can be much slower if we tend to reload the page often.

Here are other sketches (compressed!) created in a couple of hours with Processing:

We could use save('filename.tif') to save an image that we like without the need to switch to a graphics editor to crop a region of the screen. Moreover this allows us to generate images much larger than the visible area of our screens. Once the image is saved in the background, we can call exit() inside draw() to close the huge window. We should be aware to not inadvertently overwrite an image we have previously saved with a new one created by the same sketch file later. To avoid this, we can attach a number at the end of the file name. We keep the code for saving commented, experiment, uncomment it in the rare occasion of a result we like, check the file index and reload to get our file. Creating a PDF file is also possible when we need to print the image in high quality.

As you can see, in terms of speed and output, tools like Processing that are specifically made for graphics can be more powerful than the canvas available in the browser. At the same time, the browser is still better at providing universal value to everyone; it is not just for graphics we create for ourselves. It is a platform for information sharing and interactive feedback. Accessible and inclusive. Although it supports graphics, the visual is by no means used as a single communication channel. The web is much more multifaceted, which is why we so often return to it.

bit.ly/18AqhwY