Hi,
We are
suffering from the same problem that Java2D image generation is too
slow
when
it comes to time critical performance. We found that (with reference to
the
internal BufferedImage
representation):
(1)
The image generation is running in a loop such that it needs to call
getRBG()
for
every pixel. We have profiled the time with a profiler such that function
calls
are
significance if repeated numerous time.
(2) If
you are looking for generating a 1bpp image, all image format generators
did
not
generate 1bpp image properly. They are taking short cut to generate 1
byte
(8bpp)
image. The size of the image is definitely bigger than it needs to be.
Especially,
you
are looking at transferring a much larger image from disk to network (or
anything)
than
the image requires.
The
possibilities:
Based
on the previous observation, you can not beat the time performance unless
you
are
creating your own image encoder. If you select this route, the possible
approaches
are:
(A)
Make assumption about the generated image format, specifically to 1bpp or 8bpp,
you
can
directly access to the BufferedImage's pixel data buffer by
bufImage.getRaster().getDataBuffer()
and
decode the pixel directly. Once you can decode the pixel directly, you can write
to any
specific image format. The encoding performance is
boosted by approx. 100% this way.
I am
not sure. It looks to me that JVM is still bad with large number of function
calls.
(B)
Implements the encoder with C++, you are looking at more than 1000% performance
gain
for
encoding/decoding of image formats. The timing is based on profiler, not
subjective
feeling.
(C)
Implements your own means you can really write out 1bpp image, a significant
time+space
saver
on any application.
That's
all my advise. If you still want to use Java for encoding, make sure you get a
good
JIT.
This is the best optimization that you can do without
coding.
Benny
Cheung
-----Original Message-----Hi,
From: Discussion list for Java 2D API [mailto:[EMAIL PROTECTED]]On Behalf Of Adolfo Rodriguez
Sent: Thursday, March 02, 2000 5:57 AM
To: [EMAIL PROTECTED]
Subject: [JAVA2D] URGENT: 1bpp image displaywe are developing a comercial application in Java and we have many problems rendering the image, mainly because the velocity.
The images that we are trying to render to the screen are B/W (1bpp) bitmaps with around 2550*3300 pixels. We have implemented several approches but no one of them is fast enough:
- The fastest approach was java 1, by using the producer-consumer model, made a conversion from the bitmap to a bytemap (in JNI) (each bit becomes a byte) and handle Image objects. The scaling and rendering of Image objects is not so slow. However, this one was the initial approach, currently implemented in our product, which results too slow for our customers.
- After that we tried using 2D API to try to speed up the image rendering. We save time avoiding the conversion bitmap-bytemap by using BufferedImages with 1bpp, but when we tried to render the BufferedImage, we found that rendering is very fast without scaling, but as we need to scale the drawing, the performnace goes down drastically. Consequence is too slow.
The questions are:
- A new idea was: as BufferedImage creation is fast, (does not need conversion bitmap-bytemap), and Image scaling and rendering is fast (java 1), we tried the following process:
However the copy of BufferedImage on a Image is also too slow:
- create the drawing in a BufferedImage
- draw the BufferedImage in a Image offscreen
- scale and render the Image object
BufferedImage bufimg = new BufferedImage(ColorModel, raster, false, null);
img = createImage(width, height);
Graphics2D g2 = (Graphics2D)img.getGraphics();
g2.drawImage(bufimg, null, this);
bufimg.flush();
- We have also tried other options as coping the BufferedImage 1bpp to a BufferedImage TYPE_INT_RGB but all slow.
Are we doing wrong some of the previous process or the resuls that we get are expected??? Do you have any idea or workaround about how to render fast such a kind of images???
Any help would be grateful.I would appreciate a soon response since this subject is hurrying us. Thanks in advance,
Adolfo Rodriguez. ([EMAIL PROTECTED])
