Performance of Batik under Java 6.0

As I use it a lot, I tried to measure the possible boost of performance of Batik, the pure Java library which handle SVG files, under Java SE 6.0, compared to Java 5.0. I decide to create a small benchmark, similar to the one Dave Gilbert, the creator and maintainer of JFreeChart, did, some times ago.

To make it simple, I decided to benchmark the time spent by Batik from the parsing of the SVG file, to the rendering of the associated image on a JFrame. To measure the performance, I call the method 100 times (yes, maybe not enough times), and measure the elapsed time.

Finding good SVG images is not so simple, because time is not only linked to the size of the file, but also to what it contains (for example, complex renderings like gradients take much more time to compute).

And of course, I used Batik 1.7 Beta 1 and rebuilt it for Java 5.0, then 6.0, before doing all this.

Here are the results on my XP box:

Average performance boost is approx. 20%, this is good !!

For some more informations about the different SVG files that were used, they are all coming from the Batik samples library. You can get these samples either by downloading the snapshot here, or much simpler by getting them from the SVN viewer on the trunk here. For more informations about them:

• asf-logo size is 100 Ko, and it uses a lot of gradients


• batik3D size is 104 Ko


• anne size is 86 Ko


• strokeFont size is 70 Ko


• moonPhases is 95 Ko, and uses a lot of gradients


• sunRise is 67 Ko, and uses a lot of gradients


• mapWaadt is 260 Ko

If we skip those which use gradients, and the big mapWaadt image, the boost is closer to 35%. Not bad...

First real post

OK, so here is the first real post of this blog. Humm, but about what ? OK, let's dive in.

As you surely don't know, I created an open source project on java.net called MDIFramework. This is a full java framework for easing the creation of multithreaded swing applications.

When you create an application, you soon discover that :

• you need to execute the lengthy methods in separate threads to avoid "freezing" of the GUI, but then, it quickly becomes a nightmare to deal correctly with the communication between the main event thread, an even using SwingWorker is not enough (for example, what to do if you want to be sure that two actions launched by the user will be executed one after another, for example ?)


• You would like to ease the configuration of the application, an store it in the most automatic way when you close


• You want to deal with several types of files in the application, each providing different possible actions, so you would like to have some sort of metadatas associated with each opened file


• And what if you want to be able to use easily plugin with your application ?

So as I always copied and pasted the same sort of code to do the things above, I created this framework.

If you are interested, go check to tutorials here.

By the way, JSR 296 is already an upcoming Java JSR that aim to provide a simple application framework for Swing applications. I did not knew that when I created my project (but also JSR 296 is still very young), but I think that what this JSR provides (you can check the still evolving open source implementation here) is different. I should try it, and maybe add some JSR 296 capabilities to my own framework... (yes I know, why recreating the wheel when it is already existing ?).

First post in another world

Hello !!

I have already another blog on this address : http://rimmedwithfire.blogspot.com/, much, much more metallic than this one... but I would like to blog from time to time about programming, open source stuff, and things like that, so I choose to create this another one.

Hope it will be updated regularly (this is the case for the moment for my another blog).

See you !!