I think I may be reviving this site. Algorithmic and generative art has always been and continues to be something I’m very interested in. As Flash’s popularity declines, my interest in is has declined as well. Taking its place has been JavaScript and Canvas. The last few posts here were done in Canvas, but I haven’t had an established way to create pieces in JavaScript, so it has been hit or miss. Also, you can do a lot with Canvas, but the API is not quite as robust as AS3. Then there’s the fact that saving an image from a Canvas is not always quite as straightforward as is is in Flash. It can be done, but not programatically as far as I know.

A few months back I started experimenting with Windows 8 development. There, you can develop native apps in HTML5 and JavaScript. There are also hooks into system functions, and I dug up a function where I can pass in a Canvas 2d context and it will save the image as a png directly on the system hard drive. It handles Canvases up to 16,384 pixels square without a hitch. Good enough for about 4.5 feet square if printed at 300 dpi. That’s pretty much adequate for anything I can conceive doing.

So for a while, in the back of my mind, I’ve wanted to create a framework that abstracted a lot of the Canvas drawing operations into something a bit more user friendly. I finally got to work on this last week and it’s been going extremely well. I’ve actually attempted this a few times in the past, but what I came up with was never anything that I wound up wanting to use. What I have going now is working quite well for me and I’ve been able to create some pretty cool pieces with it already.

There were two other tasks I wanted this framework to make easy. Scaling and archiving.

Scaling. When I am working on a piece, I want to have it draw to a Canvas roughly the size of the screen. But at some point I may want to create a print of the canvas. Simply scaling up a finished Canvas obviously is going to look like hell since it’s bitmap not vector. So what the framework does is keep track of every operation done. You can then resize the canvas, set a scale value and play back the drawing again at the new scale. 1,600 pixels becomes 16,000. It took a bit of work, but line widths, shadows and everything else scales right up as well. Also, because all those commands are stored, they can be serialized and saved out as well. This data can be read in again, deserialized and drawn again at the same or any other scale.

Archiving. By this I mean saving the code and values that created a particular finished piece. So far, I have just messed around with code, saved out an image, messed around some more, saved another image, repeat, repeat, repeat. Then someone comes and says something like, “I like the first one. Could I get a print of that?” Well, the image was saved low res, and the code that made that particular image is long gone. So… um… not really. So here, the serializing portion comes in handy. As long as I save data as well as an image, I’m all set. I can reload that data, redraw the image in hi res as just described. But I’ve also worked out the project structure so that it’s really easy to create and fork existing experiments. So not only do I have the serialized data for an image, but it’s very easy to save the exact code that created a particular image. This is more about workflow and project setup than any fancy code. The point is I figured out an easy way to do it, so I will do it. So as long as I store the specific code for a particular image, that’s all I really have to keep around to be able to recreate that image at any size. Sounds simple enough, but it’s something I’d never worked out a good workflow for. I think I have that now.

The final interesting point about this is that since each piece is a full-fledged Windows 8 application, if I get something that works well as a standalone piece, maybe with some interaction thrown in, I can publish this in the Windows 8 Store. My first stab at this was my first published Windows 8 Store app, Particle Art. But with this more polished setup I now have, this could result in any number of published apps.

Anyway, I’m pretty excited about this now and hopefully you’ll start to see a few more images on these pages on a more regular basis.

This entry was posted in canvas, javascript. Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback.


  1. Posted February 6, 2013 at 8:06 pm | Permalink

    cool i’m excited about reading your new posts!

  2. Daniel Larsen
    Posted February 7, 2013 at 3:34 pm | Permalink

    Good to have you back! Looking forward to more awesome stuff.

  3. Posted February 15, 2013 at 3:00 am | Permalink

    glad you’re back too!
    & curious what you’ll come up with.

  4. Posted December 13, 2013 at 9:32 pm | Permalink

    Hi Keith! I know this post is almost a year old but I just happened upon it. I have been creating images in JavaScript and canvas too, and have encountered these very same issues. I have been creating large images by using a large canvas and exporting it with toDataURL() in slices (doing the whole canvas makes browsers die). But I”m really intrigued by this Windows 8 method you’re mentioning! Sounds like you’ve found a really great workflow. Any plans on sharing your secrets? Or could you point me in the right direction?

    I’ve also been working with vector images in Processing, for unlimited scalablility. That can be challenging because not everything can be done with vector images (filters, additive blending, etc), but it’s a nice solution when what you’re making can be done that way.

Leave a Reply

Your email address will not be published. Required fields are marked *

Your email address will never be published.