Torturing image ops and Swing
hendrich at informatik.uni-hamburg.de
hendrich at informatik.uni-hamburg.de
Thu Aug 3 20:28:52 UTC 2006
thanks for your detailed answers to my questions! New Niffler version
and available right now (niffler-exif.jar and niffler-src.zip).
> Right. BufferedImages created with Component.createImage(int, int) are
> backed by a Cairo surface. Ones created directly by BufferedImage are
> not. Again, this is one of these things that needs to be fixed,
> basically so that all BufferedImages can have some native backing
I added a special "classpath workaround" to Niffler that checks for
and calls ImageUtils.getCairoBackedImage( bufferedImage) before rendering when
"GNU something" is detected. This adds another image conversion (BufferedImage
drawn into an Image created by Component.createImage()), but makes the editing
operations useable with jamvm. Good.
>> 7. Perhaps LookupOp and ConvolveOp are bad? Select Tools > Rotate
>> image left (or right). Implemented 'by hand' via getRGB and setRGB.
>> Much slower than LookupOp, about 4 seconds on my system at 800x600.
> They can probably be faster, but I don't think they're the main problem
> if the times you're measuring also include the repaint time.
Nope; the times I quoted were the raw processing times, as reported by
System.currentTimeMillis() before and after the operation. Repainting times
>> Loading a 800x600 JPEG takes about 200 msecs with Toolkit, and about
>> 7 seconds with Toolkit. Loading a 3000x2000 JPEG takes 200+ seconds.
> Too slow.
Yep. Please excuse my typo there; the 7 and 200+ seconds are for jamvm and
classpath loading a 800x600 or 3000x2000 JPEG via the imageio JPEG plugin.
You can try the 10+ MPixel images from the Brussels' mort subite for
>> The imageio GIF reader is much faster (4 seconds at 3000x2000), but now
>> the conversion to BufferedImage.TYPE_INT_RGB takes 90+ seconds...
> Really? That sounds too fast, almost. How do you mean conversion?
> Running it through a filter, or just drawing the image returned by
> IIO onto the the aforementioned BufferedImagE?
You consider, 4+90 seconds too fast for 3000x2000? Wait for next years'
digicams and cellphone cams :-)
But yes; I use the same code-path for images loaded by AWT or IIO; the
ImageUtils.getBufferedImage() method creates a BufferedImage.TYPE_INT_RGB
and draws the input image into that (unless the input image already is RGB).
Otherwise, I would need a PixelGrabber to get at the pixels for the histogram.
>> Images returned by the PNG reader render as transparent.
>> 9. Select Help > Commands... A simple JTextArea in a JScrollPanel, but
>> with about 700 lines of text. Try scrolling. Painfully slow.
>> The vertical
>> scrollbar only scrolls down on click event (but dragging works).
> I'll have to check this out. drawString is fairly slow nowadays.
> However, drawGlyphVector (and by extension TextLayout.draw) are quite
> snappy, comparable to the JDK in speed. We might need to tune
> Swing here.
Should I submit another bug for this? Once upon a time, this used to be
I guess we need some technique to include performance-related tests in
Mauve for regular regression testing. Unfortunately, I don't know how to
do this, because both raw system speed and "user picky-ness" seem to
differ greatly between different systems...
> Perhaps even better you could use VolatileImage (== an X pixmap). These
> objects are slower to draw onto, but render to the screen as fast as
> they possibly could, really. (Assuming X is doing a good job)
> So if your intention is to draw-onto-bitmap-once, display-bitmap-many,
> then it should make things many many times faster.
OK. I last tried VolatimeImage when JDK 1.4 came out, and it didn't seem
like a great idea to me back then... Perhaps it's time to give VolatileImage
another chance, now...
More information about the Classpath