Skip to main content

Comparing GRIN and JavaFX

2 replies [Last post]
Joined: 2006-05-05

Hi folks,

Can anyone help enlighten me as to the differences or similiarities between GRIN and JavaFX? I've been reading the documentation for both products but am left with countless questions!

For starters let me just ask if it is correct to say that GRIN's primary offering is an animation framework while JavaFX attempts to be a full-fledged RIA platform. Is that accurate?

Many thanks...

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-02-13

Well.... That's kind of a big question.

Yes, you're generally right about GRIN, which is not to be confused with the HD cookbook project, of which it is a part. Here's how I'd split it out:

GRIN is built on top of an animation framework, com.hdcookbook.grin.animator. The animation framework was actually made to be independent of the rest of grin - if you want, you can just grab the animator package, and do drawing in Java.

The heart of GRIN is a scene graph. That is, it's a graph structure (a directed acyclic graph, plus commands) that describes a set of drawing operations. Due to the graphics API available on Blu-ray, OCAP and other PBP-based platforms, the most interesting drawing operation by far is drawImage(). That said, you can do an awful lot with image draw, cel animation (which is just a sequence of images), alpha-fade, scaling, and translation, and these are what GRIN gives you. Basically, the set of primitives in the GRIN scene graph map exactly to what Personal Basis Profile provides.

GRIN has grown to support Java as a scripting language. That is, GRIN has a threading model that means you can essentially write single-threaded code for your application logic (with, of course, a second thread for any networking). Java actually makes a wonderful scripting language when used in this way. The demos twitterGrin and weatherWidget show this technique.

JavaFX is also based around a scene graph approach, but it's one that depends on a much richer underlying graphics API. The JavaFX scripting language also requires a fair bit of runtime support.

GRIN, by way of comparison, was heavily (some might say "excessively" :-) ) optimized to minimize the number of classes in the runtime. As a result, real-world GRIN projects (that are compressed by running them through an obfuscator) fit in around 100K of code, and launch very quickly on today's Blu-ray and OCAP hardware.

The essential thing that GRIN and JavaFX have in common is the realization that a scene graph is a really flexible way to create great-looking content with a workflow that matches how graphics designers/interaction designers work.

Does this help? If you want to chat, feel free to contact me off-list, BTW.


Bill Foote
GRIN architect, Blu-ray Java Televangelist, Sun Microsystems
bill.foote at

Joined: 2006-05-05


Many thanks for the detailed reply. I think this helps.