I see that he is redrawing the whole chart on each refresh: http://github.com/joewalnes/smoothie/raw/master/smoothie.js - .save() and .restore()

One thing he can try to get speed improvements is to absolutely position a double-width canvas tag in an iframe and move the entire canvas tag one pixel to left on each refresh. Then he can just paint the new data on the right-most visible pixel. One canvas has moved -width px, just do a .save() / .restore() and reset it to left: 0px.

I'm not certain if it will help for sure but I have an inkling it might.

There was recently a series of posts about doing what you described for GTK/X:

http://audidude.com/?p=404

the result is in github:

http://github.com/chergert/uber-graph

I actually made it faster using the drawable as a circular buffer, details here http://audidude.com/?p=470

Quick cpu comparison http://x.dronelabs.com/chris/dropbox/smoothie.png

No love for Firefox? :(

I wonder why it shouldn't work on Firefox, the only bottleneck I can see is the canvas. (Websockets can be faked multiple ways.)

I've been using Chrome for the last 2 months, and today was told Firefox wasn't working with a wordpress blog I have to administer... since when does firefox have problems viewing things? I thought that was IE's job.

Tell me about it. At work I need to check Firefox too besides IE to see if the app works correctly. Chrome rarely has any problem.

Eats 100% CPU. Definitely needs a frame limiter (or whatever else is needed).

Is that in Safari?

I'm running it in chrome (on windows) on a not-great machine and it's taking 23-25% of one of the two cores.

On a Mac, Safari is at around 50% cpu and chrome is 99%

Opera on Linux.

It's also working near perfectly in Opera 10.61. (There is a bug initially, when the lines should start in the middle of the chart, rather than on the left)

No love for the iPad either. was looking forward to making a streaming dashboard with this