Re: Torturing image ops and Swing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Norman,

Thanks for the detailed report! I don't have time to try this out right now, but I have a couple of comments:

hendrich@xxxxxxxxxxxxxxxxxxxxxxxxx wrote:


1. Select menu > File > Open image directory... and select a directory with some images. This is the first challenge, because JFileChooser is still about as user-unfriendly as possible. (I somewhat fear that many first-time classpath users might give up after trying to use JFileChooser. This is
   unfortunate, because the rest of Swing works pretty well these days.)

Is this before or after Roman's JFileChooser patch (last night)?


5. Select Tools > Sharpen > Laplace 3x3. Simple convolution filter implemented
    with ConvolveOp and applied to a BufferedImage TYPE_INT_RGB.

   java.lang.ArrayIndexOutOfBoundsException: 3
   at java.awt.image.ColorModel.getComponentSize(ColorModel.java:200)
   at java.awt.image.ColorModel.coerceData(ColorModel.java:641)
at java.awt.image.DirectColorModel.coerceData(DirectColorModel.java:405)
   at java.awt.image.BufferedImage.coerceData(BufferedImage.java:288)
   at java.awt.image.ConvolveOp.filter(ConvolveOp.java:126)

This worked a week ago, but very slowly. Try the Tools > Edges > Mexican Hat 13x13 filter, if you don't believe me. The JDK seems to include some
   optimizations for such (separable?) kernels.

   OK, lets try something else:

I did some cleanup work on ConvolveOp not too long ago because it was broken. It works now, but slowly. There is a FIXME in the source code at the point where we need a different approach to get a speedup. If I recall correctly, for each pixel in the output raster, we do N x N lookups in the input raster where N x N is the size of the convolution filter. For 3 x 3, that will be slow (effectively reading the raster pixel by pixel 9 times). For 13 x 13, that will be unusable.



6. Select Tools > Negative Image. Obvious implementation based on
    LookupOp. Works. Performance is ok (1 sec for 800x600). The result is
    a BufferedImage.TYPE_INT_RGB.

    BUT repainting suddenly takes 3 seconds for each paintComponent,
and the application is pretty much dead. For comparison, a repaint of the
    BufferedImage before the filtering took about 10 msec.

    For 3000x2000 images, each repaint takes 40 seconds on my system.
    Any ideas about what I am doing wrong here are HIGHLY appreciated.

    Load a new image. Repainting time is back to the millisecond range.

Sven will probably know the answer to this. I'm sure it has something to do with the DataBuffer implementations. The source image most likely uses some private class that implements a "managed" data buffer, whereas the destination image will be using the array-based DataBuffers in java.awt.image.* (which are sure to be slower).

Anyway, thanks again for the detail...I'd love to spend some time on this right now, but alas I don't have any...

Regards,

Dave


[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux