SVG Image in JavaFX 2.2

Is there any way to display an SVG image in an JavaFX application?

Here are some options:

1. Create a WebView and load the svg image into the WebView’s WebEngine.
2. The e(fx)clipse project includes an svg to fxml converter (link now dead :().
3. This NetBeans plugin also converts svg to fxml (link now dead :().
4. You can use an awt based library like Batik or svgsalamander and convert the resultant BufferedImage to a JavaFX Image.
5. JavaFX 2.2 natively includes support for some minimal SVGPath strings (not the full SVG spec).
6. You could write a convertor which renders the svg using JavaFX Canvas GraphicsContext commands.
7. FranzXaver provides an SVGLoader, whose usage is demonstrated in the answer to: Load SVG file in a Button on JavaFX
8. https://github.com/hervegirod/fxsvgimage
   • This library allows to convert a SVG file to a JavaFX Node tree or an Image.
   • Note that contrary to other existing libraries, this library has no external dependencies (including Batik)

Or can you at least export an SVG image from javafx?

This feature sounds like a JavaFX SceneGraph to svg converter. While it is theoretically possible, I am not aware that anybody has created such a tool yet.

Does the function Node.snapshot() help there in any way?

Node.snapshot() will not help with exporting an svg image from a JavaFX scene graph as svg is a vector based format and a node snapshot is a bit mapped format.

I took a look at Batik, but it didn’t do the trick for me as it converts to BufferedImages and not to javafx.ImageView.

You can easily convert between awt BufferedImages and javafx images using SwingFXUtils.

In terms of performance – which way would you recommend?

For complex svg’s, rather than rendering from fxml, you will probably get better performance rendering to a bitmapped image or canvas graphics context. This is because your scene graph will end up a lot simpler, with far less nodes – which means that the javafx runtime will have a lot less work to do. For simple svgs (< 1000 nodes generated), it probably won’t matter too much.

Is converting an SVG to an FXML about creating instances of javafx.scene.shape.SVGPath?

Partially. The full SVG specification covers much more ground than the basic shapes. In addition gradients, effects, animations, etc can be performed by an SVG. So if the source SVG image includes those additional items, then they also need to be converted to FXML (as best they can be, there will be some aspects of SVG such as scripting which would be hard to translate to FXML).

My guess is that the size and complexity of the SVG specification is one of the reasons why no direct support for the full SVG image system is currently included in the JavaFX core API and, instead, only limited similar functionality such as SVGPath is offered. Implementing SVG natively in the JavaFX core API would have been high cost for relatively little reward when compared to other desirable items.

If that is the case, wouldn’t #2 (and #3) and #5 be just the same?

No. The NetBeans and Eclipse tools referenced in #2 and #3 were more functional than just the SVGPath facilities mentioned in #5, as those tools converted additional aspects of the the SVG specification to FXML equivalents (e.g. gradients, effects and transforms).