Up the Nile *With* a Paddle: Fun With JavaFX Graphics

With out having looked at it I would not be supprised if they are using the svg to java2d converter in flamingo. So basicly it is not another propietary graphics format. The converter takes the svg file and converts it into a java2d graphics class that you can just paint on anything you want at any size. From some of the tests that kirill did showd that it performed a little better (don't have to parse the file at run time and you don't  have to have the rather large Batik jar). So from the point of view of a RIA type of application the benifit would be that you do not have to include the rather larg batik jar you only have to incude the small generated java2d code. Any ways sounds like a good choice for what it is being used for.

Let me introduce myself first - I'm the architect and project lead of the Project Nile and I'll try to bring some light into some of the topics you are discussing.

The main motivation between Project Nile is an easy way of collaboration between a designer using professional graphics tools (Illustrator and Photoshop) and a developer using JavaFX platform. Since most of the professional graphics designers are using AI/PS we decided to go directly from those tools to JavaFX as this is the best way we can preserve fidelity. 

to Richard O: The problem with SVG it is not a direct subset, nor it supports all the features we have in JavaFX. For example not all filter effects are supported by SVG and not all features are supported by FX (e.g. attribute inheritance or defs/use element templating or animation model). So while it would be possible to create a native support for SVG, we would turn JavaFX into a SVG player which brings some advantages, but also limitations. BTW in Project Nile there is SVG2FX conversion tool, so you can easily convert your (static) SVG graphics to a content which can be loaded by JavaFX. 

 to Richard D.J.: Unfortunately we created yet another proprietary graphics format. The graphics format we have corresponds 1:1 to graphics classes you have in JavaFX. This brings one huge advantage over using existing standards: the format provides full mapping between the capabilities of the runtime and the graphics. In the case we would be using SVG or any other format, we would limit the designers to utilize all features of FX (and believe me, both AI and PS can do way more than you can describe with SVG and we can still export it to FX).Generating to Java2D commands is really not an option, as the the main usecase for the graphics you load is to further manipulate it though JavaFX as the regular scene graph objects.  This would be clearly impossible with Java2D commands. 

Also I have to note, with the preview version of Project Nile we output not only JavaFX Script code, but also a FXD file format, which is roughly a data description of the graphics we can read by the runtime. With the upcoming release I can say the focus has been on the data file format (we no longer generate the source code), as it brings many advantages over generating the code. For example

• scalability - we can load really huge graphics trees - a couple of megabytes file sizes no problem, this would be impossible with bytecode (there limits in the class file size/method size/ constant pool in the VM)
• clear separation of the designers assets (gfx files) and the developer code (scripts) - this is very important aspect allowing designers to work together with developers on the same project
• since we output data, we can easily process them in tools and do both read/write of this format (this would be very difficult with code)
• with data we can do optimizations for less capable devices without recompiling the application
• we can support dynamic loading of graphics, thus features like skinning are very easy 

We are going to release the version 1.0 next week. It will be freely available, so you definitely should check it out. We have samples you can easily play with to see what I mean by the above.