Hi Julian,
The number of possible combinations for source and destination
images and video hardware is rather large for me to make any
definitive estimates of what you will see without further
information.
We have done nothing in 1.3 to improve the performance of copying
offscreen images to the screen, only Toolkit images have been
improved (and mainly 8-bit have seen the vast improvements). These
offscreen images are distinct from other images loaded from a file
or URL or generated by an ImageProducer. Basically Java has two
different kinds of images that were implemented using different
native mechanisms in 1.1:
offscreen images created with "createImage(w, h);"
toolkit or media images created with getImage(file/URL)
or createImage(ImageProducer)
JDK 1.1 used a very efficient mechanism provided by GDI for the
first type of image that would blit to the screen very fast. The
other type of image used a different GDI mechanism that was stored
in system memory and could not take advantage of hardware acceleration.
JDK 1.2 and later use the BufferedImage mechanism for all types of
images and that mechanism is currently designed to store images only
in system memory (the Java Heap to exactly describe the current
implementations). The BufferedImage mechanism is also more capable
than either of the image options that 1.1 provided.
I don't know what Win32 applications you are comparing our 24-bit
performance to. I also do not know what screen depth you are
drawing to or what type of video card you are using (PCI? AGP?
AGP 2X? how much VRAM?). All of these things affect the performance.
Drawing deep (i.e. 24-bit) toolkit/media images on an 8-bit or 16-bit
screen will (still) be slower than JDK 1.1, but JDK 1.1 essentially
cheated by dithering the image down in depth to match the screen. This
was fine for simple copies to the screen since the dithering would have
to be done for that operation anyway, but it would affect the quality of
any type of scaling operation or rendering the images to deep offscreen
buffers for other types of image manipulation since those kinds of
operations need the raw original data to reduce accumulation errors.
Since JDK 1.2 and later provide lots of facilities for performing
arbitrary manipulation of images, we now store the images in the
original format of the ImageProducer/media file instead of always
converting the storage format to the screen type. Thus, rendering
a 24-bit JPEG to a 16-bit screen means color reducing it for each
blit operation in JDK 1.2+, instead of doing it once up-front in
JDK 1.1.
How JDK 1.1 (or 1.2+) compares to the native Win32 applications depends
on the design of those applications and I'm afraid that I don't have
any crystal ball about how a particular application is designed, but
I can make some guesses as to how they were designed that might give
better performance. If they store the images in VRAM, then they can
take advantage of hardware acceleration for the blits to the screen.
The downside is that the Windows APIs for doing this are very limited
and so you run into one of two problems, depending on how you accomplish
this. Either you store the image in an HBITMAP you get from the
CreateCompatibleBitmap call in which case you have no direct access
to the pixels (you have to copy pixels in and out to filter or manipulate
them), or you can use a DirectDraw Surface object which allows you to
access the pixels directly but also gives Windows permission to throw
the bits out at any time with no pre-notification. Both of those
problems are stumbling blocks for the 2D API that we need to find a way
around before we can take advantage of VRAM blits.
But, if your application is displaying on 24-bit or 32-bit (TrueColor)
screen depth then we should be rendering the TYPE_INT_RGB images to the
screen about as fast as any other Win32 application that did not use
VRAM to store their images. There will be a slight improvement in the
throughput of this operation between 1.2/1.3beta and 1.3 fcs, but not
a significant improvement - all performance figures are in a similar
ballpark (all we did was tweak the compiler flags for those operations).
...jim
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
