http://jsfiddle.net/alpha123/eZ7GQ/

I don’t really have much experience with canvas, and I wish I had the time to learn enough to do something freaky like Pete, but I don’t, so excuse the primitive-ness. At least it has undo, which is something I didn’t see in any of the other ones.

http://www.chromeweblab.com/sketchbots

http://jsfiddle.net/u922h/

Okay, I promise. I’m done now. Have a great weekend, all!

http://jsfiddle.net/FGAun/

Maybe. Or at least I’ve been too ambitious for a Friday afternoon.

Here is my relatively simple solution: http://jsfiddle.net/Dimcho/tqnwQ/

• vanilla JavaScript :)
• code ‘packed’ in an object
• no reloading canvas
• additional image with CSS absolute positioning
• no animation (at least for now)

Best regards

In this design, I simplified Turtle into a StatelessTurtle and leveraged the existing Animator to perform the drawing with a somewhat different role. (Loose coupling FTW!)

I added two more helpers. UnifiedCaller takes an object (in our case a context) as a template and builds a new object with the same method that can call its functions on a variable number of other objects. This allows you to call transforms once and have them apply to both the turtle and the drawing context.

The other helper, OffscreenRenderer, takes a canvas and lets you generate any number of contexts to composite onto it. Compositing is triggered with the render method.

http://jsfiddle.net/Rocka84/pxvTe/

The benchmarks show exactly what I expected, by removing the O(n) build complexity for each frame, the performance goes WAY up. I added a benchmark utility to each of my previous solutions to clock and demonstrate the advantage.

Keep in mind that my code puts a 1/60th second delay between each frame draw. Since the Nyan draw takes 2092 frames, there’s a baseline of 35 seconds to complete the Nyan. I performed the benchmarks on my iPhone 4S because it accentuates the performance gains and it’s a common platform you can test with yourself (if you have one). So without further ado, here’s the results (complete with updated code to include benchmark tool):

• No optimization (http://jsfiddle.net/vEn7u/): Nyaned in 71 seconds
• Reduced history size (http://jsfiddle.net/e962g/): Nyaned in 51 seconds
• Elimination of history queue (http://jsfiddle.net/axe63/): Nyaned in 37 seconds

Interesting note: On the last version, my iPhone actually out-performs my desktop by about a second. Also, remember that these numbers INCLUDE the 35 seconds of delay. So really we should talk in terms of processing time (time taken in addition to the 35 seconds of delay), and if we look at that, the performance gains are staggering:

• No optimization: 36 seconds of processing time
• Reduced history size: 16 seconds of processing time
• Removal of history queue: 2 seconds of processing time

So yeah, the performance gains from eliminating the per-frame re-draw are astounding.

Here’s my tweak to your solution: http://jsfiddle.net/bnickel/xttSL/3/

I like your context transform approach. It’s very clean.

Animation in Canvas is actually pretty tough (as others might be figuring out). Essentially, you have to draw your entire screen many times per second, and if (like us) you’re “constructing” the canvas from historical data, the obvious (and typical) solution is to keep a history of all that data and “replay” it every frame to generate the current view, then add on whatever should have changed.

So, for instance, in my original code, if you wanted to draw a line 10 pixels long, it would add 10 entries to its “(animation) queue” array, each drawing one pixel of the line. Each frame, the front of the queue would be pushed to the back of the “history” array and the entire history array would be drawn. Obviously, this means that after only short sessions, this history array would grow quite long. I’ve updated the code to allow you to easily view the length of your history (see the “History Length (debug)” button:

http://jsfiddle.net/g4ZdX/

After running the Nyan macro (see the “NYAN!” button), the history length would be about 2000. And each of those 2000 steps must be re-performed up to 60 times per second. This resulted in noticeable performance degradation when running on my iPhone 4S.

So how to improve this? Well, I had a couple ideas.

The easiest to implement had to do with trimming the number of entries in the history queue. Arian’s implementation does something similar to this. Essentially, it takes into account that drawing 10 1-pixel lines takes more processing power than drawing 1 10-pixel line, and has the same effect. In Arian’s case, he refrains from pushing “uncompleted animations” to the history queue (or rather, replaces the tail of the queue with each subsequent “animation step”). My solution is similar, but slightly more efficient. I keep track of the type of action (a color change, rotation, or push forward) and if the type of action performed by the tail of my history queue matches the head of my animation queue, it will merge them and combine their values (or, in the case of a color change, replace the value) to produce a single step that will perform both actions. Here’s the result:

http://jsfiddle.net/2T8v4/

Now the NYAN macro only adds 281 entries to the history queue, which is much better, but still not ideal. The performance of each frame render still clocks in at O(n), so your algorithms professor would tell you that there’s no actual improvement here. And she’d be right.

So how to improve this more?

Well, the obvious solution is to retain the complete rendered screen and only perform the differences between the current frame and the next frame. This problem is actually ideal for such a solution because each subsequent frame will contain ALL the contents of the previous frame (assuming you don’t reset the board and can exclude your cursor). Additionally, Canvas offers most of the tools (note the “most”) to carry this out in a simple fashion (see: context.getImageData and context.putImageData). So the frame render algorithm would look something like this:

Restore the previously recorded frame (if any) Draw new data Record the frame Draw the cursor

It’s that simple. Except the trick is that in order to save a hundred lines of code or so, my solution to this puzzle made use of Canvas’s built-in transformation utility. And while this makes it very easy to perform all the drawing, there’s no way to export your transform matrix in order to redraw your cursor in the correct position. This means that you still need to retain and re-perform all your historical transforms. And as noted before, this continues to lock us into linear (O(n)) complexity for each frame draw! How frustrating!

The good news is that the good folks at the W3C seem to have also noticed this issue and the Canvas spec has been updated to include context.currentTransform in order to retrieve (and save) the current transform. But no browsers aside from Mozilla have implemented this feature yet. So it’s very unsafe to use. People have written their own transform classes to “solve” this problem, but that’s still an awkward solution.

So what other solution might we have? Well, even though it seems like a big hack (and it is), the best solution I’ve come up with is to simply place the cursor on a second (overlapping) canvas element. That way, we can clear and re-draw the cursor without popping the transform, and also draw all new data to the other canvas without actually having to refresh it. This results in huge increase in performance. In fact, it reduces the complexity of each frame draw to a big, fat, constant O(1). I’m working on implementing that, it’s a bit tricky, but in the end, it’s probably the most efficient solution to handle animation without a per-frame overhead that increases with each action.

/whew

This is reminiscent of a Turtle program my dad wrote when I was a kid as an introduction to programming. All components are broken into loosely coupled units which report changes via events. The application itself listens to events and renders the result.

One feature of this design is that the turtle caret is not part of the rendering itself meaning the drawing doesn’t need to be replayed after every step. All changes to the canvas are permanent and performance won’t degrade as the drawing gets bigger. (That said, performance issues probably won’t surface for renderings of this size.)