Mark Stephens

Mark Stephens has been working with Java and PDF since 1999 and has diversified into HTML5, SVG and JavaFX.

He also enjoys speaking at conferences and has been a Speaker at user groups, Business of Software, Seybold and JavaOne conferences. He has a very dry sense of humor and an MA in Medieval History for which he has not yet found a practical use.

Major change to Color performance in newer Java releases

1 min read

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 a 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 our 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?

If you’re a first-time reader, or simply want to be notified when we post new articles and updates, you can keep up to date by social media (TwitterFacebook and Google+) or the Blog RSS.

Mark Stephens

Mark Stephens has been working with Java and PDF since 1999 and has diversified into HTML5, SVG and JavaFX.

He also enjoys speaking at conferences and has been a Speaker at user groups, Business of Software, Seybold and JavaOne conferences. He has a very dry sense of humor and an MA in Medieval History for which he has not yet found a practical use.

Leave a Reply

Your email address will not be published. Required fields are marked *