Major change to Color performance in newer Java releases

Over the last month, we noticed a major slowdown in our regression tests. A test cycle which used to take 30 minutes was taking 82 minutes. So we dug deeper to see what was going on….

In our Java PDF viewer and PDF to HTML5 converter, we do a lot of conversion of image data to sRGB. To do this we use a ColorConvert operation. So to convert CMYK image data to sRGB, we would use this code, with a filter to convert the data.

ColorSpace CMYK=DeviceCMYKColorSpace.getColorSpaceInstance();

ColorSpace rgbCS=GenericColorSpace.getColorSpaceInstance();

ColorModel rgbModel = new ComponentColorModel(rgbCS, new int[] { 8, 8, 8 }, false, false, ColorModel.OPAQUE, DataBuffer.TYPE_BYTE);

ColorConvertOp CSToRGB = new ColorConvertOp(CMYK, rgbCS, ColorSpaces.hints);

WritableRaster rgbRaster =rgbModel.createCompatibleWritableRaster(w, h);

CSToRGB.filter(ras, rgbRaster);
image =new BufferedImage(w,h,BufferedImage.TYPE_INT_RGB);
image.setData(rgbRaster);

In general, we try to use Oracle’s built-in functionality. In theory, it should be able to take advantage of hardware acceleration and native code, and allow us to write shorter cleaner code.

What we found was that filter() was now much slower – so slow in fact that it is now quicker for us to write our own pure Java method to convert the image data directly. We raised this as an issue with Oracle and it is now an official bug in the Oracle bug database.

The reason for the change is that one of the underlying libraries used by Oracle has been changed (Little CMS is now being used instead of KCMS). You can still use KCMS (Kodak Color Management System) with an unofficial JVM flag (-Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider), but LittleCMS is now the default and KCMS will disappear in the meantime.

The reason for the change is perfectly understandable. But it does raise some interesting issues and potential performance headaches for Java developers (especially if you need to support multiple JVMs).

Our solution to the problem has been to refactor our code that all .filter() calls are handled by a single static method where we can choose between old and use methods depending on the JVM in use. It also means it is easy for us to enable/disable.

So if you are seeing some odd performance issues in your Java code, you may find this change is the cause of the issue. And if you a customer, this fix will be in the monthly April software releases of our Java PDF library and PDF to HTML converter out this week.

What are your experiences of the change to the new library in Java?