Bug 28422 - ConvolveOp troubles
Summary: ConvolveOp troubles
Status: RESOLVED FIXED
Alias: None
Product: classpath
Classification: Unclassified
Component: awt (show other bugs)
Version: 0.92
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-18 16:42 UTC by Norman Hendrich
Modified: 2006-07-19 18:46 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Proposed patch (1.84 KB, patch)
2006-07-19 14:55 UTC, david.gilbert
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.