Processing ported to JavaScript | Hacker News Reader

Processing ported to JavaScript

ejohn.org

112 pointstzury28 comments

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.

"... Converts the canvas to a binary image ..."

Just realised that in fox3 right mouse click on the canvas allows you to save the image as a .png

You can also save an image via the toDataUrl method of a canvas object: http://www.whatwg.org/specs/web-apps/current-work/#todataurl

More canvas goodness:

http://www.abrahamjoffe.com.au/ben/canvascape/

add the textures and watch your browser slowwwww

Not if you're using Safari!

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!

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).

Yup it does, and it's been recently added to the spec (http://www.whatwg.org/specs/web-apps/current-work/#text). Unfortunately, the font rendering as currently in the spec won't return the path of the font, which is a feature that allows nodebox to do some really neat things (eg http://nodebox.net/code/index.php/LetterKnitter).

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'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.

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?

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?

Not yet, I've looked at it a bit but haven't looked in to browser compatability at all.

Processing.js now supports Ture Type Fonts: http://processingjs.org/source/ttf-pfonts/ttf-pfont-pjs.html

I mean TrueType fonts of course :P

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.

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.

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.

File size of a Processing.js compared to a Java app is generally smaller.

I did a quick test and got 22kb overhead with the JS version and 233kb overhead with the Java Applet, that's WITH the library included.

More details here:

http://processingjs.org/reference/articles/comparing-process...

Wow, I'm very impressed. Looking forward to playing with this.

Why not make a JavaScript API instead of Processing?

A-M-A-Z-I-N-G

Reply on news.ycombinator.com