Bug 28422

Summary: ConvolveOp troubles
Product: classpath Reporter: Norman Hendrich <hendrich>
Component: awtAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: bug-classpath, david.gilbert
Priority: P3    
Version: 0.92   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed:
Attachments: Proposed patch

Description Norman Hendrich 2006-07-18 16:42:09 UTC
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)
Comment 1 david.gilbert 2006-07-19 14:55:44 UTC
Created attachment 11913 [details]
Proposed patch
Comment 2 david.gilbert 2006-07-19 14:57:04 UTC
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.
Comment 3 Norman Hendrich 2006-07-19 18:46:29 UTC
(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.