Hello Sven,
thanks for your detailed answers to my questions! New Niffler version
uploaded
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
buffer.)
Hmmm... ok.
I added a special "classpath workaround" to Niffler that checks for
"java.vendor"
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
are extra...
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
yourself...
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
PR24152...
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...
Thanks,
Norman
