Hi Jim,
The acceleration of 8-bit source images for the upcoming release of 1.3 is very good
news. Just curious, will loading, manipulating and displaying 24-bit, true color
images be faster as well? Bug# 4276423 refers to the "drawImage of an offscreen image
to the screen" being slow. Is this part of what you have previously discussed and has
been fixed in Java2D in the upcoming JDK 1.3 release?
I haven't really compared image performance to the earlier JDKs, but in simple
comparisons to native Win32 applications, loading large 24-bit images (say
1280x1024x24bits, no transparency, BufferedImage: TYPE_INT_RGB) is between 6X and 10X
slower depending on the host computer's memory configuration. I know the performance
problem is primarily related to the fact that the offscreen image buffer is in normal
memory instead of VRAM. The question I have is on what release of Java will this be
addressed? Will it be the final release of 1.3 or a later version?
Thank you,
Julian L Brown
Opinion One
[EMAIL PROTECTED]
-----Original Message-----
From: Discussion list for Java 2D API
[mailto:[EMAIL PROTECTED]]On Behalf Of Jim Graham
Sent: Tuesday, October 26, 1999 10:37 PM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA2D] BufferedImage vs MemoryImageSource
Hi Kenneth,
A BufferedImage will almost always give you a better result than
a MemoryImageSource for your application. But, JDK 1.2 will not
give you a better result than JDK 1.1 unless your 8-bit images
have transparency in them. The upcoming JDK 1.3 should give you
equal or better results than JDK 1.1 for 8-bit source images and
then the BufferedImage will be another boost on top of that.
The MemoryImageSource must feed the data to the Toolkit image object
through the ImageProducer/ImageConsumer interface into an internal
private pixel buffer from which the pixels get copied to the screen.
The BufferedImage will avoid that copy. Poorly written loops in
JDK 1.2 made 8-bit source images display slowly on most displays
to an extent which would negate the BufferedImage performance
benefit over 1.1 APIs.
Some specifics which depend on the image format:
8-bit all opaque images only perform on par with 1.1 at TrueColor
depth on Windows in JDK 1.2. The performance loss at all other
depths can be 2x to 3x.
8-bit images with transparency should draw faster on JDK 1.2 and
later than JDK 1.1 (in some cases dramatically faster). Both
are still slower than the speed of opaque 8-bit images on JDK 1.1
so simply adding a transparent pixel to your opaque images is
not a workaround to the slowdown on 1.2.
Gray images are really bad on JDK 1.2 unless you have at least
one non-gray color in the lookup table or a transparent entry.
With the color entry or transparent entry, they perform the same
as their non-gray counterparts (see above).
JDK 1.3 will achieve parity with JDK 1.1 on 8-bit opaque images
and maintain or extend the lead for 8-bit transparent images
(both gray and non-gray).
Scaling an image on JDK 1.2 or later will incur a 20% to 45%
performance penalty.
Note that we haven't done exhaustive testing of all display cards
but the Matrox Millenium and ATI Rage 128 cards that we did the
tuning on showed very similar performance ratios between the
various releases. The benchmark was using MemoryImageSource
images to drive the tests.
...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".
===========================================================================
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".
