29 comments

[ 3.7 ms ] story [ 117 ms ] thread
Wow, I'd love to use this to generate dynamic graphs with text - but does it support text?
Canvas itself does not support text; there are various hacks to, e.g., port PS fonts to canvas, but it's a really ugly scene. Other methods include overlaying HTML text via CSS and server-side image rendering fonts. It's all really ugly.
Firefox 3 supports native text rendering. There's a couple demos that show this (although you're out in the cold in other browsers, for now at least).
Is there any word on whether other browsers will be implementing this in the future? It's what's keeping me from using canvas today, and partially what's keeping me from writing a certain app I've been thinking about for a little while.
partially what's keeping me from writing a certain app I've been thinking about for a little while

Have you played with SVG?

In my experience it's painfully slow and advanced features are spottily supported on every implementation I've tried; is yours different?
I'm using it for a simple web app, testing in FF2/FF3/Safari, seems to work fine... there are some annoying bugs in the implementation (the kind that have been open for years), and inconsistencies between Safari and FF, but nothing I couldn't work around so far.

What were your issues?

I've tested some of my SVG demos with FF 3 and they run much faster than with FF 2 (I think that's due to Cairo being integrated into Firefox 3). Opera and Safari are very fast compared to FF 2, too.

As for feature completeness I agree with you. The Firefox SVG team is very small and not funded by the Mozilla corporation (at least that was the case last year when I talked to one of its members) - the SVG standard, on the other hand, is HUGE.

Not yet, I've looked at it a bit but haven't looked in to browser compatability at all.
We started by using graphviz to generate svg, but then couldn't find any decent in-line svg viewers. Do you know of any non-java applet inline svg viewers?
This is pretty sweet, I've been a big fan of Processing for ages.

Processing reminds me of what was great about languages like QBasic. You could draw graphics on the screen and animate them without needing to understand how to use complicated graphics libraries.

It doesn't necessarily need to be fast, it just needs to be easy and fast-enough!

(comment deleted)
Long live the king of JavaScript.
"... Processing ported to JavaScript ..."

My project just got a lot more interesting. One of the things I was having trouble with is generating an image from data with severe constraints on modules & processing time. Processing.js fills the gap of PIL which I couldn't use. I'm finding more and more interesting JS modules. Take this one for instance ~ http://www.nihilogic.dk/labs/canvas2image/ Converts the canvas to a binary image.

Wow, I'm very impressed. Looking forward to playing with this.
Needless to say this is very cool.

Could someone explain the technical advantages of having it in javascript rather than as a java applet?

Obviously java applets are a pain, but at least right now they much more widely supported than the canvas element.

Are they? At least for my tech-oriented blog, the percentage of visitors using canvas-compatible browsers and the percentage with Java applets enabled is roughly the same. And the former is bound to get higher while the latter goes the other way. So for sites that have a high ratio of non-IE users that are concerned about subjecting those users to the various Java applet pains.
In my testing the JavaScript version had a better "boot time" (it was able to begin showing results instantly) - and rendered better/faster for simple examples. However, the Java Applets simply scale better. They can handle pretty much anything you throw at them. If you're just tackling simple stuff (pretty much anything that I demoed on the site) then Processing/Canvas is probably the way to go.
Why not make a JavaScript API instead of Processing?