JDK-4883787 : REG: Rendering a TYPE_CUSTOM buffered image (read using ImageIO) takes long time
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2003-06-25
  • Updated: 2014-03-18
Related Reports
Relates :  
JDK-6427776 - Method Graphics2D.drawImage(...) stops a run of program
Relates :  
JDK-6381195 - ImageIO creates images of type CUSTOM for some common formats
Description
I have written an application using ImageIO to read a JPEG image from a file. I have obtained the supported destination image types from the reader by calling JPEGImageReader.getImageTypes() and there were 3 image types. out of the three, I have set the destination of the ImageReadParam to the third image type specifier which is of buff image type TYPE_CUSTOM. The image has been successfully read using the reader. But when I tried to render the buffered image returned by the reader, it took very long time to render and the time taken in Mantis and Tiger are abnormally high. This is seen on Solaris as well as Windows. Whenever I resize the frame, the CPU utilization shoots up to 100% on Win32 platforms and other applications freeze until this image is rendered.
I have given the statistics below:

Win32 (Win XP):
---------------

1.5.0 - b06    -  20603 ms
1.5.0 - PIT    -  21453 ms
1.4.2 - b27    -  20187 ms
1.4.0 - b92    -  3844  ms
1.4.1 - b21    -  3812  ms

Solaris 8
---------

1.5.0 - b06    -  109527 ms
1.5.0 - PIT    -  110750 ms
1.4.2 - b27    -  103142 ms
1.4.1 - b21    -  22019  ms
1.4.0 - b92    -  22110  ms

From the above data, you can very well notice that the time taken in mantis and tiger are abnormally high. I have also tested on Win NT in addition to the above platforms and I am able to reproduce this. 

I have attached a sample code. Execute the sample code and watch the console. It will print out the time taken for rendering the buffered image. Compare the value with the above data. If they match approx, then the bug is reproduced.
Comments
Please re-open if - if fix is in progress or on the plan to fix soon - if this is a P3 (file as P3, not P4)
18-03-2014
WORK AROUND There are a few workarounds here that help improve performance: - Allow the image to get into its "managed" state (where we create/use an accelerated copy of it). This usually happens on the second copy from the image to the back buffer or screen, so the rendering speed dramatically improves on the third copy (note that this is mostly a tip for Windows, where we have hardware acceleration for managed images). Note that you will still suffer bad rendering performance on the first 2 drawImage() calls with this workaround. - Don't specify CUSTOM explicitly, but instead let ImageIO figure out the best image type. Do this by simply calling ImageIO.read(File) or ImageIO.read(FileStream) with the appropriate parameter. My tests with this approach showed all rendering times to be insignificant as the BufferedImage type created was not CUSTOM and therefore did not fall into this performance regression situation. This workaround saves rendering time on every copy; the only possible downside is that I do not know whether there was an explicit reason that the user actually needed the image type to be CUSTOM. - Create an intermediate image of some other type of BufferedImage, copy to that image, and thereafter use that non-CUSTOM image. For example, I ran a test where I created bimg of type INT_ARGB, got the Graphics for that image, called drawImage() from the original CUSTOM image, and thereafter used the ARGB bimg as the source for my drawImage() calls. The rendering time was insignificant because this approach avoids falling into the CUSTOM regression. Note that the initial copy to the intermediate image will still take a long time as it is falling into the same rendering trap brought up in this bug report. ###@###.### 2004-09-02
02-09-2004
EVALUATION This isn't a regression (its slow in all releases) and custom image types DO take a long time to draw, that's not unexpected, no matter what the image source (ie its nothing to do with image i/o). ###@###.### 2003-06-25 ============================ Reading the bug report properly(!) it is clear that the rendering is 5x slower in 1.4.2, so this needs to be assigned over to classes2D for further evaluation. ###@###.### 2003-06-25 ============================ This appears to be related to some regression in either our rendering speed for CUSTOM BufferedImages or in ImageIO's creation or usage of that type. If we avoid the use of the CUSTOM type, then the rendering speed goes down to almost nothing. Also, this type of image is managed on 1.5, so (at least on Windows) on the third copy from this image, we will use an accelerated version of the image to copy from and again the rendering time goes down to almost nothing. Workarounds are posted in the Work Around section. ###@###.### 2004-09-02
02-09-2004