java.awt.image.ConvolveOp is rather broken atm: (1) Sooner or later an IndexOutOfBoundsException is thrown. The operation never completes. See below for an example stacktrace. Sorry, no testcase yet (will try to submit one later). (2) The code includes some wait loops ;-) java/awt/image/ConvolveOp.java, 263ff: for (int y = src.getMinY(); y < src.getHeight() + src.getMinY(); y++) for (int x = src.getMinX(); x< src.getWidth() + src.getMinX(); x++) { } for (int y = src.getMinY(); y < src.getHeight() + src.getMinY(); y++) for (int x = src.getMinX(); x< src.getWidth() + src.getMinX(); x++) { } (3) Performance is dismal (the example stacktrace below is for a 640x480 rgb image with 3x3 kernel: jamvm takes 12 seconds to get to the IOOBE, while jdk 1.4.2 takes 60 msec to complete the filtering. This gets worse with larger images and kernels. For example, the jdk needs 343 msec for a 13x13 kernel on the 640x480 image, while jamvm takes about 5 minutes to get to the IOOBE.) Cacao is slightly faster than jamvm but tends to throw OutOfMemoryErrors on larger images, for unknown reasons. -Xmx200m should be enough for filtering a single 640x480 image. java.lang.IndexOutOfBoundsException: 307200 size: 307200 at gnu.java.awt.peer.gtk.CairoSurface.getElem(CairoSurface.java:283) at java.awt.image.DataBuffer.getElem(DataBuffer.java:292) at java.awt.image.SinglePixelPackedSampleModel.getSample(SinglePixelPackedSam pleModel.java:411) at java.awt.image.SampleModel.getSampleFloat(SampleModel.java:493) at java.awt.image.SampleModel.getSamples(SampleModel.java:587) at java.awt.image.Raster.getSamples(Raster.java:886) at java.awt.image.ConvolveOp.filter(ConvolveOp.java:245) at java.awt.image.ConvolveOp.filter(ConvolveOp.java:134) at niffler.actions.ConvolveAction.execute(ConvolveAction.java:45) at niffler.actions.NifflerAction.actionPerformed(NifflerAction.java:30)
Created attachment 11913 [details] Proposed patch
I've attached a patch that should fix (1) and (2), but is unlikely to improve the performance of this class. Please give it a try.
(In reply to comment #2) > I've attached a patch that should fix (1) and (2), but is unlikely to improve > the performance of this class. Please give it a try. Thanks! Confirmed; the patch seems to fix (1) and (2). That is, my application now survives the filter() operation, and the results of simple kernels look ok. However, lacking nice testcases I didn't check the output images for correctness. For some reasons that I don't yet understand, trying to paint() the result images is extremely slow (about 3 seconds per repaint for 640x480 ARGB with ARGB DirectColorModel) and makes my app completely unuseable. For example, opening a menu triggers a few repaints, each of which takes 3 seconds... Still, I'm closing this now.