Jim has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

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

11.26.2008
| 5497 views |
  • submit to reddit

I've often mentioned the importance of programmers and graphics designers working together to create great looking RIAs.  The declarative syntax of JavaFX facilitates this approach, and the "Project Nile" tool available with the JavaFX SDK makes this even easier.

Sten_breakout  

Try your hand at the "Breakout" style game that Sten posted on his blog, and then read about how he collaborated with a graphic designer (his five-year-old daughter) to create this game in JavaFX.  Sten discusses in his post how he used Project Nile to export graphics-related JavaFX code from Adobe Illustrator using Project Nile.

On a related note, Silveira Neto (whose JavaFX fun I've featured on this blog before) participated in creating a plug-in for Inkscape that exports SVG in the form of JavaFX code.  

Inkscape_draw_with

That Silveira has all the fun!  Regards,

Jim Weaver
JavaFXpert.com

 

Published at DZone with permission of its author, Jim Weaver.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Richard Osbaldeston replied on Wed, 2008/11/26 - 9:45am

Was it not possible to have native support for SVG rather than have to go through the rigmarole of convertion into yet another intermediate (propietary?) graphics format? Seems like a faff and Swing would stand to benefit from scable icon/gfx support too.

Richard D. Jackson replied on Wed, 2008/11/26 - 11:35am in response to: Richard Osbaldeston

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.

 

Richard D. Jackson replied on Wed, 2008/11/26 - 11:41am

Well after writting the above post I went and actually read what the plugin does and it is doing kinda of what I thought they are converting it to code but not to Java2D code which is too bad as that would be handy for swing devs as well. They are instead converting the svg file to JavaFX code. But they are still getting the same benifit in that they only have to include the generated code into the RIA and not all the parsers and such.

Martin Brehovsky replied on Wed, 2008/11/26 - 7:58pm

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. 

 

 

Osvaldo Doederlein replied on Sun, 2008/11/30 - 7:19am in response to: Martin Brehovsky

[quote=mb118009] 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.
[/quote]

An additional advantage is that you don't overload the JVM with the many overheads of classloading (parsing, verification, interpretation, JIT, filling the PermGen, class-GC). Using Java code (either source or bytecode) as a persistent format for virtually ANYTHING is a terrible idea.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.