Time to get serious about this blog, and about my drawing project, which I have called ‘draw.’
Canvas is based on a very simple concept, which is that most of the screen painting is done by function calls that move a cursor from point to point. It almost reminds me of the turtle graphics programming I did in the late seventies and early eighties in Logo and GraFORTH, although that was a bit different in that the cursor movements in turtle graphics are relative (Move forward 10, turn right 45 degrees, Move forward 14.1421, etc.) as opposed to Canvas’ absolute positioning (Move from point [10, 20] to point [10, 10], Move to point [20, 0], etc.). Back then there were a lot of unusual programming paradigms being foisted on children by academic purists championing their favorite obscure language — Logo was a version of Lisp, and GraFORTH was a version of FORTH. GraFORTH is in fact currently so obscure that it doesn’t even have a Wikipedia page.
But I digress. Another post will delve more fully into the early years, and the relative virtues of functional and stack-based languages. Today I want to talk about what I’m going to do next with the ‘draw’ project. Since the class ended, I have made a few minor tweaks to it, but the reason I have continued to work on it at all is so that I can one day make it into a multi-user real-time app.
If you search around for two seconds you can find any number of much more elaborate drawing apps using Canvas, like this one for instance, which looks like frickin’ Photoshop. But ‘draw’ has the virtue of being really simple, as in something a very small child might be able to use on an iPad, as in something my niece and nephew in California might be able to use at the same time as me, drawing on the same canvas (I live in New York).
To accomplish something like that I knew I would need Node.js, and probably socket.io as well. I just barely have a handle on those technologies, but I have been to a couple of hackathons and worked doing front-end coding on teams of people who knew Node really well, so I have a good idea of what it can do, and I figured this was the perfect project to learn it on, from start to finish.
So a couple weeks ago I made myself a list of steps I’ll have to take:
- Set up the ability to have multiple simultaneous brushes.
- Set up a Node.js server that receives and sends brush move events to and from multiple clients.
- Set up hosting for that server on the Internets.
- Set up a history object, so that when a new user opens their browser to the drawing app, everything that has happened so far is reflected on their canvas. (This is an important point for those who may not be familiar with Canvas, because it’s pretty low-level. Unless you use some kind of abstraction layer on top of it, all Canvas knows is the current operation, plus the pixels that have already been displayed on the screen. If you want to recreate the drawing history, you’ll have to keep track of it yourself.)
- Set up a way to create multiple canvases, each with their own name, so everyone in the world isn’t drawing on the same canvas (all with the ability to clear the screen at any moment!) People can start new ones or click on links or go to previously defined URLs for the old ones.
- Various UX and design changes and fixes, most notably the ability to handle touch events.
I actually did #1 and #4 pretty quickly. For a proof of concept of #1, I added a second brush that is operated by the keyboard, so that I can use that one and the mouse one at the same time. For #4, I set up a ‘restore canvas’ button so that I could clear it and then test the browser’s ability to reconstruct it from the history. It does so in the blink of an eye. I was surprised. Computers these days!
So for #2, which is of course the heart of the matter (although #3 might be kind of tricky…), I am plowing through the partially-published Manning book “Node in Action,” and of course all of the excellent information available online about Node.js. I should have something to show for myself in a week or two. Wish me luck.