/*

drawImage is very slow in JDK 1.2rc1. My "Plasma" benchmark at
http://rsb.info.nih.gov/plasma/ runs at 1/2 speed compared to JDK 1.1.7.

Details:
   JDK 1.1.7 speed: 89 frames per second 
   JDK 1.2rc1 speed: 46 frames per second
    OS: Windows 95
    Machine: P2/400, 64MB
    Graphics: ATI 3D Rage Pro
    Display depth: 16-bits

Source code is at:
    http://rsb.info.nih.gov/plasma/source.html

This applet creates an animated display by summing four
sine waves into an array. Example FPS rates are at
http://rsb.info.nih.gov/plasma.
It is based on "Sam's Java Plasma Applet"
(http://www.dur.ac.uk/~d405ua/Plasma.html) by Sam Marshall
(t-  xxxxx@xxxxx  ). It was modified to use 8-bit images
by Menno van Gangelen (  xxxxx@xxxxx  ).

Here is what the applet tag used to run
the Plasma benchmark looks like:

    <applet code="Plasma.class" width=320 height=240>
       <param name=scale value="2">
       <param name=showfps value="true">
    </applet>

*/

import java.awt.*;
import java.awt.image.*;

public class Plasma extends java.applet.Applet implements Runnable {
  Image img;
  Thread runThread;
  long firstFrame, frames, fps;
  int width, height;
  int w,h,size;
  int scale=3;
  boolean showFPS = true;
  IndexColorModel icm;
  int[] waveTable;
  byte[][] paletteTable;
  byte[] pixels;

  public void init() {
     width = size().width;
     height = size().height;
     String p = getParameter("scale");
     if (p != null)
        scale = Integer.parseInt(p);
     p = getParameter("showfps");
     if (p != null)
         showFPS = p.equals("true");
     w = width/scale;
     h = w;
     size = (int) ((w+h)/2)*4;
     pixels = new byte[w*h];
     waveTable = new int[size];
     paletteTable = new byte[3][256];
     calculatePaletteTable();
     img=createImage(new MemoryImageSource(w,h,icm,pixels,0,w));
  }

  public void start() {
     if (runThread == null) {
       runThread=new Thread(this);
       runThread.start();
       firstFrame=System.currentTimeMillis();
       frames = 0;
     };
  }

  public void stop() {
    if (runThread != null) {
       runThread.stop();
       runThread=null;
    }
  }

  public void update(Graphics g) {
     img.flush();
     g.drawImage(img, 0, 0, width, height, null);
     if (showFPS) {
        frames++;
        fps = (frames*10000) / (System.currentTimeMillis()-firstFrame);
        g.drawString(fps/10 + "." + fps%10 + " fps", 2, height - 2);
     }
  }

  void calculateWaveTable() {
    for(int i=0;i<size;i++)
       waveTable[i]=(int)(32*(1+Math.sin(((double)i*2*Math.PI)/size)));
  }

  int FadeBetween(int start,int end,int proportion) {
    return ((end-start)*proportion)/128+start;
  }

  void calculatePaletteTable() {
     for(int i=0;i<128;i++) {
        paletteTable[0][i]=(byte)FadeBetween(0,255,i);
        paletteTable[1][i]=(byte)0;
        paletteTable[2][i]=(byte)FadeBetween(255,0,i);
     }
     for(int i=0;i<128;i++) {
        paletteTable[0][i+128]=(byte)FadeBetween(255,0,i);
        paletteTable[1][i+128]=(byte)0;
        paletteTable[2][i+128]=(byte)FadeBetween(0,255,i);
     }
     icm = new IndexColorModel(8, 256, paletteTable[0], paletteTable[1], paletteTable[2]);
  }

  public void run() {
    int x,y;
    int index;
    int tempval,result;
    int spd1=2,spd2=5,spd3=1,spd4=4;
    int pos1=0,pos2=0,pos3=0,pos4=0;
    int tpos1,tpos2,tpos3,tpos4;
    int inc1=6,inc2=3,inc3=3,inc4=9;

    runThread.setPriority(Thread.MIN_PRIORITY);
    calculateWaveTable();
    while(true) {
      index=0;
      tpos1=pos1; tpos2=pos2;
      for(y=0;y<h;y++) {
        tpos3=pos3; tpos4=pos4;
        tpos1%=size; tpos2%=size;
        tempval=waveTable[tpos1] + waveTable[tpos2];
        for(x=0;x<w;x++) {
          tpos3%=size; tpos4%=size;
          result=tempval + waveTable[tpos3] + waveTable[tpos4];
          pixels[index++]=(byte)result;
          tpos3+=inc3; tpos4+=inc4;
        }
        tpos1+=inc1; tpos2+=inc2;
      }
      pos1+=spd1; pos2+=spd2; pos3+=spd3; pos4+=spd4;
      repaint();
      Thread.yield();
      //try {Thread.sleep(10);}
      //catch (InterruptedException e) { }
    }
  }

}

(Review ID: 41544)
======================================================================

I know of no workaround.
======================================================================

This has been identified as a key area by the JDK performance team.
  xxxxx@xxxxx   1999-01-12

I've been looking into this bug via the built-in 1.2 hprof profiler, and OptimizeIt.  

Looking at the Plasma demo which is shown in the bug description (with OptimizeIt) it quickly shows up that most of the time is not spent blitting the actual bits to the screen.  It turns out that the current implementation of drawImage creates an intermediate representation of the image when scaling is required.  This causes memory to be allocated, and extra memory copying to be done.  It seemed that 60-70% of the time was being taken up by this memory allocation.  I tried tweaking the html page to create a non-scaled version of the image and found that I could get frame rates of over 70-fps, where before I could only get 10-15%.

I also looked at the submitter's ImageJ <http://rsb.info.nih.gov/ij/> program's Waves option (at the submitters request).  For this trial I used the built-in 1.2 hprof profiler.  This showed that almost 37% of the time (the largest component) is taken up by the setDataElements() function.  This turns out to be part of the producer/consumer chain.  For 1.2 this code was moved from C to Java, and may be suffering effects from array bounds checking, or other problem.  I haven't yet dug into this yet.  There also is some memory allocation going on here of a similar type to mentioned above, but it only accounts for about 10%.

More to come later.

  xxxxx@xxxxx   1999-02-02

-----------------------------------------------

I've also tested a case supplied by   xxxxx@xxxxx  .  His test case renders grayscale images.  I've attached the source code to his test case to this bug.

I ran his test case against OptimizeIt (pressing the applet's button several times).  Like the plama benchmark, this one had a large %-age of it's time taken up in DataBufferInt.<init>.  Below is a the stack trace which lead to the construction of these objects:

java.awt.image.DataBufferInt.<init>()
java.awt.image.Raster.createPackedRaster()
java.awt.image.DirectColorModel.createCompatibleWritableRaster()
sun.java2d.loops.LockableRaster.<init>()
sun.java2d.loops.RasterOutputManager.convertFrom()
sun.java2d.loops.RasterOutputManager.performOpaqueBlit()
sun.java2d.loops.RasterOutputManager.compositeSrcDst()
sun.java2d.loops.RasterOutputManager.renderImage()
sun.java2d.SunGraphics2D.renderingPipeImage()
sun.java2d.SunGraphics2D.drawImage()
sun.awt.image.BufferedImageGraphics2D.drawImage()
sun.awt.image.ImageRepresentation.drawToBufImage()
sun.awt.image.BufferedImageGraphics2D.drawImage()
com.mitra.jimageqa.TestDraw$ImagePanel.paint()

What's interesting about this case is that it doesn't involve image scaling (as the Plasma demo does).  This seems to be the result of translating between color models.  It seems that we don't have loops to handle some of these color models, and this requires a conversion to a color model we have a loop for.  This conversion is done each time we paint.

  xxxxx@xxxxx   1999-02-09

   There are a number of reasons that drawImage in JDK1.2+ is slower than
JDK1.1.  We are trying to address some of the problems but it will not
be solved for Kestrel.  One reason is that we currently do not store the
image into hardware buffers.  That is an optimization that we still hope
to implement but have not as yet.  (It might be easier to do so when
Jim finishes the new pipeline architecture -- however that is slated for
the next major release after Kestrel.)  Another big reason is that we
are slow when we scale images.  JDK1.1 scaled images directly into
the pixmap.  We currently scale images into a BufferedImage and then
blit it so we have a lot more overhead.  Getting rid of the extra
BufferedImage will be easier with Jim's new architecture.  Another reason is
that there is a lot of overhead in our rendering pipeline (and Jim's work will
have cleaned that up).  Jim has made some of our blitting loops more
efficient (and these changes will be in Kestrel FCS) so there will be
some noticeable changes there.

  xxxxx@xxxxx   1999-09-07

The Plasma demo suffers primarily from a lack of direct-to-screen image
scaling code (bug #4268962).  If you remove the scaling then it suffers
a lesser amount from the inefficiency of the 8-bit rendering loops which
convert the source palette entry for each destination pixel rather than
converting the palette once up front and then using a lookup for each
pixel (bug #4268438).

The com.mitra demo suffers a bit from the inefficiency of the 8-bit loops
when running with 8-bit grayscale (bug #4268438) and from a bug in the
way that DirectColorModels construct their Rasters in the 24-bit grayscale
mode (bug #4275538).

I have tried to download the latest ImageJ program, but unfortunately it
no longer seems to have the "Test Display Speed" option so I am at a loss
as to how to reproduce or investigate the problems with that application.

In any case, the primary focus of this bug is the Plasma demo as it was
originally submitted.  The problems in the Plasma demo are really a
duplicate of 4268438, which was fixed for 1.3FCS and 4268962 which will
probably not be fixed for JDK1.3.  Thus, I am closing this bug as a
duplicate of the 4268962 bug - the main remaining performance bottleneck
which affects the Plasma demo.

Other more specific bugs dealing with drawImage performance will be opened
as new problems are identified.  Since drawImage is just a front end for
a very complex matrix of operations, no single bug could ever describe
problems with such a system as generally as the synopsis for this bug
would suggest.

  xxxxx@xxxxx   1999-09-24

Developers looking for a list of related bugs identifying specific
performance issues with drawImage should examine the following list
of bugids to see if these bugs represent their concerns.  Note that
some of these bugs are already fixed in an upcoming release.

4268962 Scaled drawImage slow in 1.2 due to use of intermediate buffers
4204845 Remote use of double buffering on JDK 1.2 is very slow
4276423 drawImage of offscreen image to screen much slower in JDK 1.2
4276434 Specifying alpha component for opaque images will slow rendering
4275538 DirectColorModel.isCompatibleRaster is overly strict
4272634 compiler flags hurt the performance of some of the rendering loops
4268438 drawImage from 8-bit image to a 15/16/24/32 bit destination is slow

  xxxxx@xxxxx   1999-09-29

its true

Our estimate was 3 times slower

The "Test Display Speed" command in my Image/J program
(http://rsb.info.nih.gov/ij/) shows that drawImage in 1.2 is up to 118 times
slower!
                             Screen Depth
                           8-bit 16-bit 32-bit
  JDK 1.2rc1, 8-bit image:  5.4    7.1   8.8
  JDK 1.2rc1, RGB image:    1.0    1.0   .95
  JDK 1.1.7, 8-bit image:   118    64    16
  JDK 1.1.7, RGB image:     118    64    16
  
  Tests were run on a Pentium II/400 with ATI Rage
  3D Pro graphics running Windows 95. Results are
  in millions of pixels per second. Test images
  were created using Image/J's File New command.

We checked jdk1.2rc1 against jdk1.2beta4 and
found the same problem...

I don't understand what mechanism causes this, what
improvement would be worth the performance loss.

My animation component which uses drawImage
a lot has become a lot slower too, which results
in lower frame rates. (Tested on 1.2b4,1.2rc1)
I cannot think of a reason why this problem 
occurs, because any graphics accelerator card 
can do this very fast (bitblt).
Of course, it might be needed to check some
things when performing a drawImage because
of the different kind of off-screen images
that can be used. But I just use the default
one, which does not have any features (like
transparency) that cannot be accelerated.
Oh well, let's hope that this issue is resolved
in one of the first bugfix releases. Given
the changes between rc1 and rc2, I don't think
the fix will make it in 1.2.0

No workaround yet! My estimates were 2.5 to 3 times
slower.

I am also seeing this.  In addition, painting becomes very slow if you have
overlapping window.

My test program ran in 2 seconds in JDK 1.1.7 and the same programe ran in 202
seconds under JDK 1.2.  
Please improve the performance on printing under JDK 1.2.

same results for me.

All those interested in the graphics performance
problem should see, and possibly vote for, bug
4189070 also.
This kills Swing performance to the point where it is
unuseable.  We were waiting for 1.2 to release to
deliver our applications because we wanted the better
performance and Java2D capabilities.
Given that the existance of this bug has been known
for quite sometime and hasn't gotten fixed yet, we
are looking at dropping 1.2 specific code and back
porting our products back to 1.1 so we can get good
GUI performance.  Yeah, we'll have to live without some
of the Java2D printing support, but it doesn't look like
there is really much more there anyway, at least nothing
that anyone has been able to demonstrate to me.

I am sending 8-bit IndexColor  (256 grays, no alpha) data into an
java.awt.Image object  via the standard Producer/Consumer model.  I draw
to an (cached) offscreen image created by Component.createImage(w,h),
and then draw it to the screen.
This is 5x slower in JDK1.2 than JDK1.1.7 when drawing to
a 16-bit depth screen (on NT4.0), and 10x 
slower when drawing to a 16-million color screen.
I get about 120ms for a 500x700 image in JDK1.1.7,
and 750-1200 ms in JDK1.2 .
This makes JDK1.2 unusable for imaging programs,
which is the biggest reason Java2D was written.

drawImage bug still seems to be there
in JDK 1.2 final? Can anyone confirm this?

This plain sux and in my case kept me from going from 1.1.7 yo 1.2,
because the performance impact on my program is just too big. Plz
fix it!

same for me...framerates of 1.9fps on a pII-300
running solaris 2.7...

I've noticed a similar slowdown when trying to fill a page with text using
drawString() in a paint method. 
The drawing has gone from blazingly fast under 1.1.6 and 1.1.7 to
excruciatingly slow with 1.2 (Windows NT 4). 
An eyeball estimate is that 1.2 is probably 100 times slower than 1.1.7. 
I am forced to revert to 1.1.7 until this bug is fixed. 
Please undo whatever you did to Graphics between 1.1.7 and 1.2 - the current
implementation is absolutely intolerable.

I am having the same problem as rwri002. The bug still exist on 1.2.
I had to go back to 1.1.7 because of it. 

Even drawing in old awt components is very
slow under jdk1.2. I can't run any Graphics.drawLine()etc. statements what 
forces me to go back to jdk1.1.7.
Obviously the bug is not a 2D bug or a Swing 
problem but graphics in general.

Java 1.2 drawImage is not slower in all cases. 
On my computer I saw a faster frame rate on a 
couple game applets of mine. A rough estimate is
that the games' frame rate is 1.6 times faster on 
Java 1.2 (compared to Java 1.1.7). The games call
g.drawImage() once per frame, and the images are 
320x240, 8-bit color, created from a home-made 
MemoryImageSource-like class. 
The test machiene is a P200, 64MB, Win98. 
(You can try the games at 
http://www.cs.unt.edu/~brackeen)

This bug make impossible for me to use version 1.2!
I will continue to use 1.1.7

This bug was giving really bad frame rates for
a simple test application (in some cases 1 frame
every 4 seconds). After a bit of investigation
most of the time was being spent reformatting a
24-bit RGB image to the color scheme used by the
display. Using JNI and C to reformat the color
information to the same as that used by the
display brought the frame rate up to over 50
frames a second. While this isn't an option in
most cases it does indicate that Sun have some
work to do in this area.

I think this bug is among the most detrimental
hinderences to adequate Java application development.
 Please fix soon!
(T)

Fix it please.

Overall Java 2 Swing performance is completely
unacceptable. With a simple prototype that only
displays more than 60 components in a panel
and no other processing or logic is running in
the background, scrolling through the panel is
*very* jumpy. Recompiling and running under 1.1.7B
does not shows this behaviour. Same thing using
Swing 1.1.1 Beta 1 under both SDKs.
Sun needs to do some real work on tunning the
overall performance of the Java 1.2 graphics/AWT/
Swing packages - and needs to do this fast.

TRY THIS: DO NOT USE a graphics from 
.getGraphics() to draw! It was ok on jdk117 but
now I can even see string being drawn one at a time!
You must store your
changes then call repaint(x,y,w,h) over the needed
zone. It is very bad, but the gain is immediate.
The graphics passed to paint IS NOT the same
class that the one from getGraphics.
More, since you will store the rendering state,
make your own myRealUpdate(g) method to bring
back the the old mecanism of update(g), which
has been stupidly bypassed for whatever crap
that slows down the rendering.
MORE: on drawImage(), the imageObserver should
not repaint on each damn line received! If it is
the Component itself, override the imageUpdate
to delay the repainting (timer of whatever, look
in the source code of Component).

JDK1.2 is unusable for us until the performance problems
 with drawString() have been fixed.  I'm getting worried
 about the time it seems is necessary to fixed this bug!

drawImage is faster when the image drawn is created using createImage(w,h) than
when it's created using createImage(new MemoryImageSource(...)). The speed can
be somewhat improved if you first draw the image created with MemoryImageSource
on an Image created with createImage(w,h), even if it's done for every frame.
When done for every frame, you can double the speed, so that it's only about 50
times slower instead of 100 compared to jdk1.x:(

From Maurice Snell, Snell & Wilcox Ltd.
We have an image viewer application that gives
acceptable performance under 1.1.6 or earlier,
but is so slow as to be useless under 1.2.  The
slow down is similar on Win95 and NT, and has
been reproduced easily on multiple machines.
In our real application, the slow down is about 20
times worse in 1.2 compared with previous Java versions.
In this simple program that just draws large
bitmaps to the screen, 1.2 is 20-100 times slower
depending on machine, OS, etc.

import java.awt.*;
import java.awt.event.*;
import java.awt.image.*;
/** Test the speed of basic image display function.
 * @author Violet Snell, Snell & Wilcox
 */
public class GraphicsTest
extends Frame
{
	
	/** Constant used for full alpha value. */	
	public final static int ALPHA = 0xFF<<24;
	public static final int NUM_IMAGES = 50;
	public static final int X_SIZE = 200;
	public static final int Y_SIZE = 200;
	
	public Image[] images = new Image[NUM_IMAGES];
	public PictureBox pictureBox=new PictureBox();
	public GraphicsTest()
	{
		//Create the images
		for (int im=0;im<NUM_IMAGES;im++)
		{
			int[] data = new int[X_SIZE*Y_SIZE];
			for (int x=0;x<X_SIZE;x++)
				for (int y=0;y<Y_SIZE;y++)
				{
					int g = 100+im;
					int r = g+x;
					int b = g+y;
					data[y*Y_SIZE+x]=ALPHA|(r<<16)|(g<<8)|b;
				}
			images[im] = createImage(new MemoryImageSource(
				X_SIZE, Y_SIZE, data, 0, X_SIZE));		
		}
		add(pictureBox);
		addWindowListener(new WindowAdapter(){
			public void windowClosing(WindowEvent event){System.exit(0);}
		});
		pack();
	}
	
	/** The contents of the frame. Draws the images in sequence.
	*/
	public class PictureBox
	extends Canvas
	{
		int index=0;
		long startTime=0;
		/**	Returns	a dimension	containing the preferred size of the picture.
		 *	@return	the	width and height of	the	<code>PictureBox</code>,
in
		 *	pixels,	contained in a <code>Dimension</code>. */
		public Dimension getPreferredSize()
		{
			// Return the current size of the picture box.
			return new Dimension(X_SIZE, Y_SIZE);
		}
		/**	Paints the images.
		 *	it moves on	to the next	image in the sequence once this	image has
		 *	been painted.
		 *
		 *	@param g  the graphics object to use for painting.*/
		public void	update(Graphics g)
		{
			g.drawImage(images[index],0,0,X_SIZE,Y_SIZE,this);
		}
		/**	Paints the images.
		 *	it moves on	to the next	image in the sequence once this	image has
		 *	been painted.
		 *
		 *	@param g  the graphics object to use for painting.*/
		public void	dopaint()
		throws InterruptedException
		{
			if(--index<0)
			{
				index=NUM_IMAGES-1;
				if(startTime>0)
				{
					System.out.println("Took "+
					  (System.currentTimeMillis()-startTime)/1e3+
					   "s to paint "+NUM_IMAGES+" images");
					synchronized(this)
					{
						wait(2000);
					}
				}
				startTime=System.currentTimeMillis();
			}
			update(getGraphics());
		}
		
	}
	
	public static void main(String[] args)
	throws InterruptedException
	{
		GraphicsTest test=new GraphicsTest();
		test.show();
		while(true)
		{
			test.pictureBox.dopaint();
		}
	}
}
Here

Yes, it is.

The slow handling of images is a area that needs to be improved. The java
engines needs to take advantage of the capabilities of the platform e.g. like
Java 3d uses directX.  

I think Sun will fix it by using DirectX/3D for some
of their graphics needs.

Same problem experienced here also. Heres a work-around that I use to give the
impression that a JWindow splash screen is drawing faster. (It probably won't
be much use in a lot of cases)
private void showSplash()
{
  setSize(1, 1); 
  show();  // will result in a call to paint(...)
  setSize(this.width, this.height);
}
By setting the size to 1,1 (0,0 does not work) then displaying the JWindow, and
then resizing it you dont see the image (slowly) being drawn.

hmmm..

It is unlikely that I will be moving from 1.1 to 1.2 until this bug has been
fixed

Sorry to muddy the waters a bit further.
I have found the performance of SWING applications
using JDK 1.2 (Solaris and Linux) and displaying
on an X-terminal to be appalling.
Using the profiler it appears that a significant
amount of the time is taken up waiting to unlock
the graphics resource. As the following snippet
shows:
CPU SAMPLES BEGIN (total = 1212) Thu Mar 18 09:11:38 1999
rank   self  accum   count trace method
   1 48.51% 48.51%     588   215
sun/awt/motif/X11Graphics.X11UnLockViewResources
   2 21.78% 70.30%     264    89 sun/awt/motif/MToolkit.run
   3  2.48% 72.77%      30    86 sun/awt/motif/MToolkit.init
   4  1.40% 74.17%      17   206
sun/java2d/loops/IntDiscreteRenderer.devSetRect
   5  0.83% 75.00%      10   190 cmr/lib/map/TileCoastlineReader.open
   6  0.83% 75.83%      10    95 sun/awt/motif/MToolkit.loadSystemColors
   7  0.66% 76.49%       8   214
sun/java2d/loops/DefaultComponent.IntIsomorphicCopy
   8  0.58% 77.06%       7    94 sun/awt/motif/MComponentPeer.setFont
   9  0.58% 77.64%       7    13 java/lang/ClassLoader.findBootstrapClass
  10  0.58% 78.22%       7    77
javax/swing/plaf/metal/MetalLookAndFeel.initComponentDefaults
  11  0.41% 78.63%       5    88 sun/awt/motif/MFramePeer.create
  12  0.41% 79.04%       5   131 java/lang/Class.forName0
  13  0.33% 79.37%       4    24 java/util/zip/ZipFile.read
  14  0.33% 79.70%       4    36 java/lang/String.<init>
If I disable double buffering (and hence the
drawing of images), the performance is acceptable,
unfortunately the applications flickers like a
1920s movie.
If Sun are addressing the Image drawing issue,
then please take note, this needs to be
correct too.
PS: The Win95/NT version does not show this
problem.

First, please make loops for all the combinations.
Hire an intern if you have to. :-)
MMX or (similar hardware) for scaling and color model
changes could really speed things up.  Also, if 
support for multiprocessors was added for high 
performance systems.  This of course
would be a change to the JVMs native code.

I do realize the long term value of having this
internal code in Java.  But the performance hit is too
great.
However, it might be better to keep the internal code in
Java but have the JVM recognize similar MMX type
optimizations.  Then not only will the color and
scale be much faster.  Any Java program could see
the speed increase.
Thank you,
Adam Ratica - CE96

We see the 1.2 slowdown on Solaris, but
the DEC JDK 1.2beta on a DEC Alpha is fine.

You can solve the drawImage problem by using a 
DirectColorModel without alpha-channels in 
combination with HotSpot.
Create you images using something like this:
ColorModel colormodel = new DirectColorModel(24,
 0xFF0000,0xFF00,0xFF);
createImage(new MemoryImageSource(width, 
 height, colormodel , pixels, 0, width));
This has only been tested under NT4.0 with SP4.
Hope this helps!

I've been developing a 3D engine and I've used an
old version of my code as a benchmark for various
Java VM's. Here are the results so far: (na =
using a DirectColorModel without alpha)
VM                        fps       na fps
MS Jview 5.00.3167        12        14
JDK 1.1.8                 12        15
IBM JDK 1.1.7             13        16
JDK 1.2.1 classic VM       3         ?
JDK 1.2.1 HotSpot VM       3        11
My computer is an IBM 390 Thinkpad laptop with a
Pentium 233 MMX and 64 MB ram running Windows 98.
The 3D engine draws into an int array which using
MemoryImageSource updates an Image which is then
drawn to the screen.
I think the benchmark data speaks for itself. JDK
1.2.1 is hopelessly slow without using the
DirectColorModel workaround suggested by jak1. But
even with that workaround, and even with HotSpot,
JDK 1.2.1 is still slower than JDK 1.1.8, though
no longer catastrophically slower.
Swing also seems so much slower with JDK 1.2.1 than
for instance with MS Jview that it's practically
unusable on my 233 MMX laptop.

HELLO!
Are you doing anything about this bug?!?!
Last evaluation if from 1999-02-09! Don't keep us in the dark!!!!!!!

Does Sun know how important this problem is? Does Sun care about the client
side Java momentum that is growing? Does Sun understand how problems like this
are going to delay if not kill the acceptance of Java 2? Does Sun listen to the
people that WILL make or break Java - THE DEVELOPERS? I suggest Sun start
listening and responding! Maybe Sun can start here:
http://www.javalobby.org/servlet/News?action=displayStories&xsl=comment.xsl&format=full&id=500300000000200

I think this has become the crucial issue for Java. Solve it and Java will
become big on the client, too. Please put all of your effort into this one
issue.
I don't mind waiting until July if you do a good job.

relax guys, and have faith in Sun.
they'll deliver.  unlike OTHER
companies out there, to date they 
have delivered everything they promised

I posted a previous email stating that speeds
were 7-10 times slower for drawImage in jdk1.2
as compared to 1.1.7 .  I even gave a test
program to Sun, which they have profiled, and
mentioned above in the analysis phase (I am
the last xxxxx@xxxxx).
I was using a HP Kayak PII 300 with a built-in 
Cirus Logic (I think an S3) video card.  I have 
just upgraded computers, and have a new video
card.  Guess what!  The speed isn't slow any
more.  I haven't benchmarked whether it is
better or worse than 1.1, but it is comparable
(except Java memory is jumping around a lot,
and GC is going off a lot).
Before, it was almost like the JDK got confused
as to the screen bit depth, and had to
re-convert the data line by line during drawImage.
On the new computer things are fine.
So, either my old card (and others) are at fault,
or Sun has some bugs dealing with different
graphics card configurations.  
While the memory
use and raw conversion speed needs to be
optimized as much as possible, I am no longer
the incredulous angry poster near the top of
this list.

Actually, after extensive testing, I am about
twice as slow with JDK1.2.1 with Hotspot vs.
JDK1.1.7 .  This needs improvement!

Could this also be affecting general Swing performance?
I have an applet that draws some very simple graphics (in a JPanel), yet has a
terribly slow update rate.
Is the normal Swing double-buffering image-handling slowed down by this problem
as well?

Definitely kills Swing performance, in fact from
a UI standpoint, it makes Swing unuseable on many
user's computers.  I'd love to switch to Java2,
but cannot afford to have our products negatively
impacted by this nor all of the support calls we'd
take if we did switch to Java2.
I'm waiting for these graphics performance issues
to be resolved before I can even consider switching
to Java2 and recommending others to do so as well.

We are working on Medical Image Visualisation.
We have spent quite a long time to work around this bug. 
Now we will switch back to 1.1.7. If this bug persists in 
future we will give up developing in Java, because all 
the advantages of this language can not compensate this one.

This still isn't fixed in 1.2.2EA!
How many more votes does SUN need?
Keep voting!  Lets see if we can get it over 1000!

JDK 1.2.2 RC is out and... look here
http://developer.java.sun.com/developer/earlyAccess/j2sdk122/relnotes.html
the bug is still with us !

In your fixed bugs section you state at bug 
#4105679 that this issue is fixed...
I have doubts...
                        

a new release of the jdk and this bug still exists, sounds like we are having
some problems
please fix this before the final release.

Well, Sun and NeXT used GUIs that were entirely rendered with Postscript
(Display Postscript) which supports all the power that Java2D has. So obviously,
you can run a gui ontop of a flexible 2D engine.

Has Sun considered splitting out the 2D API into a standard extension? In the
old 1.x AWT, performance for 9/10ths of all applications was acceptable. For
one, I think that support for antialiasing and coordinate-space transforms is a
bit of overkill for most applications, like drawing most user-interface
components.
Let me put it this way: Does a graphics package like CorelDraw or Adobe
Illustrator use the same engine for rendering page information as for drawing
its menubars and buttons? Of course not. The reason is that using such an
engine is overkill. 
I, for one, could make use of a package like "javax.2D", written
almost exactly the way it is now, with backward compatibility to
java.awt.Graphics. That way, if I got to a point in my development where I
realized that I needed color space transforms and fancy fills, I could just
import the extension class, change the parent class of my component to
"javax.2D.Canvas2D" or something similar, and keep going.
Anyone else have thoughts on the subject?

Not having this bug fixed in 1.2.2 is very disappointing.
Bug #4189070 (another significant graphics performance
problem) was changed from being fixed for the 1.2.2
release to being fixed for a non-public release.  Thus
it appears that none of the graphics performance issues
are going to be resolved anytime soon, if ever.
This is interesting, Sun is carefully and
calculatingly removing support for Solaris x86
desktop and now Java appears to be headed the same
way with client side Java as Java2 is not a viable
client side platform with these graphics performance
problems.  Also, Sun has announced neither.  Is this
the writing on the wall that Sun has given up the
desktop totally ?
I apparently have to rethink my position on supporting
Java on the client.  If support for client side Java
goes away, as it appears to be, there will be no place
for server side java either.  You can't do one side
successfully without the other, especially server side
only as the specialized nature of many of these applications
and the way they are built don't normally suffer as much
from cross platform problems and many people don't mind
locking themselves into a single server platform.

It's unbelievable that this bug is still there !
SUN is going to loose all confidence...

rjcl: Early Silicon Graphics machines, like the Personal Iris (and early IBM
RS6000s, IIRC), also used Display PostScript (under the name 4Sight) for the
window manager. You could even edit (hack) the PS files it used to do daft
things like make menus appear at random angles and still work. By today's
standards those machines are boat-anchors but the GUI performance was perfectly
acceptable.
I *want* to use Java2/Swing. It's a good-looking, powerful and flexible GUI,
but if the performance doesn't stop sucking like a starved leech it's in
trouble.

Why do Germans always spell 'lose' with two o's?

Please fix this problem.

Has anyone considered that this may be caused
by jdk1.2's use of the ARGB pixel format instead
of the more common RGBA ?

Please give us an idea of when this will be fixed

James Gosling recently was interviewed in
connection with JavaOne99 and had this
to say about 2D and Swing performance:
"There is room for performance improvement
in the new 2D graphics libraries in the
Java 2 platform; these certainly need
some tuning. One of the persistent
performance problems we've had that
has been pretty hard to grapple with
involves the demand for features:
people keep asking us to put this
in and put that in. Look at "Project Swing,"
for example. "Project Swing" is this
UI toolkit that is industrial-strength.
It's got everything in there, and that
makes it kind of big. And big always
turns into a performance problem.
So we're working on ways to try to
make "Project Swing" faster, trim
it down, and give it fewer interdependencies,
so that it is fast and nimble.
(http://www.javaworld.com/javaworld/javaone99/j1-99-gosling.html)

I afraid its a <aol>me too</aol>.
JDK1.2.x w/wo HotSpot using Swing is too slow on Solaris (UltraSparc10) (okay
on my works Pentium II 400/400 though). I think my particular problems are
drawString() as has been mentioned before.  I try to use all my votes on this.

please fix it as soon as possible

Can someone summarize how pervasive this problem is?  Eg, profiling a run of a
fairly non-graphical Swing application with Numega's TrueTime reveals a number
of 2D classes showing up in the top dozen or so functions; eg, LockableRaster,
BufferedImageGraphics2D, SunGraphics2D, etc.
("Fairly non-graphical" = components like text boxes, buttons, etc.
without images - there are graphics in a toolbar, but that's it.)
However, while true that things attributable to 2D classes take 20% of the
execution time (at least as profiled by TrueTime), this falls far short of the
300% or worse performance hit cited by some posts here. Swing performance seems
crummy, and it does seem some of it can be blamed on java2d, but in my case it
is fairly high but not as extreme as some of you seem to be seeing.
Granted, this is a non-image intensive application and the problem seems much
more acute with image-intensive aplications.

The root cause of this problem lies in the way
1.2 handles images and text. 1.2 performs all the
rendering and color space conversions in software
whereas in 1.1 this was done by the hardware (X
or Windows). AWT simply passes a buffer to the
X or Windows libaries to render them. In 1.2
java2d is responsible for copying pixels, 
color conversions (8bit, 24bit etc) and this
is best done in hardware. All video cards
have dedicated logic to do this. It is senseless
to do this in software. 
To add to this problem, on a Remote display, AWT
first gets the source from the remote display with
XGetImage and then renders the image pixel by pixel
on to this buffer and then puts it back with
XPutImage, This is extremely expensive.  This has
to be redesigned if JavaSoft wants to fix this
problem.

Okay.  JDK 1.2.2FCS is out and this bug is STILL open!!  In a couple months
we'll have a one-year anniversary from the submission.  Considering that the
bug is in the very top of the votes and it's the single most wicked problem for
client apps in Java2, I'm just dazzled that the bug is still here.  :(

bleading edge guys: if you don't like
to bleed, please don't use 1.2 - it's buggy
:-)

We're not moving to 1.2 until this one's fixed:
our app which works great on 1.1 runs like a dog
under 1.2.2.  I just can't believe that Sun is
unable to fix the top reported bug on JDC, but
has fixed a whole bunch of bugs with less than 10
votes.  Do they actually take any notice of these
votes at all?

when are we going to see some status on this apart from in progress. 

Please don't release JDK 1.2.2 to AOL/Netscape for inclusion in Netscape
Communicator 5.0 until this bug has been fixed.  Thanks.
http://www.javasoft.com/pr/1999/06/pr990616-02.html

Why cannot Sun Microsystems just have someone put something here to just ensure
us that they are working on it?  Are they not paying attention to it?  Come on.
 This is rediculous.  It's been more than half a year and yet not response. 
This almost got me fed up with Sun.  I actually thought that Sun was a
promising company.  I'm doubting that now.

you guys should really stop bashing SUN, as that
is most certainly _not_ going to fix the problem.
I mean, if you were _really_ committed to
getting it fixed, you would download the
Java Source and fix it yourselves!!  Otherwise
you're all just a bunch of complainers!

actually 1.2.2 is not buggy at all!  rather,
it's far far more reliable than any of the
other java versions!  i'm pretty happy with it!

duale is right. SUN doesn't solve bugs. The bug parade is just a place to find
bugs. Thats about it.

What I have found with this bug:
First, I have been teaching how to write games in 
Java and have created a subclass of Frame that has
the game sprites drawn inside of it. I also have a
thread object (called an AIEngine) that looks after
moving sprites around and figuring out where they
should move next. This thread calls the Frame that
instantiated it by calling its repaint() method.
Making calls to a Frame's repaint() method from the
thread seems to really mess with the Event queue,
(i.e. repainting does not seem to take place in 1.2)
If you obscure the Frame as its loading in 1.2, then
the animation takes place inside the Frame but it
is strobe like in nature (i.e. images are redrawn
occasionally but seem to bounce around the screen).
The "supposed fix" that the AWT team recommended to
me when I e-mailed them was to replace the repaint()
calls with update. This allows the application to
work but at the expense of about 1/4 the frame rate
as the exact same program running in 1.1.
Calling update more than once actually slows down
the application since it refreshes the entire screen.
I am baffled at reading all of the comments in this thread
since it has become quite clear that this issue is
VERY important to the Java community and that Sun
has not even responded to this group with at least a
5 minute "we are on the problem" response.
There seems to be a lot of fustration because of the
"apparent" lack of commitment (key word being apparent),
by Sun to fix this bug which has existed for a whole
year now.
Personally, I am teaching "kids camp" courses to children,
ages 11 - 16 at BCIT in Vancouver BC Canada. We have
had to drop down to JDK1.1 which was a shame because
the 100 odd kids that we have taught Java to would
have greatly benefitted from learning Swing instead
of the AWT.
I think that without a commitment from Sun on this
issue within the next couple of months will force me
to reconsider teaching the kids next year games
programming in Java and instead revert to games 
programming in C/C++.
Sun, if you guys are listening, you might want to
at least let us know what your plans are so that
we can plan accordingly.

*laffs*  yeah, whatever dreammachine.  
Like you're really going to find a reasonable
C/C++ graphics library to code in.  I would
like you to just _try_ and code in ActiveX.
You wouldn't last an hour with that garbage,
much less your teeny boppers.

I'm using MS VC++ for several years and I thought that Microsoft don't listen
to developers. It was a mistake. If I compare their response time to Sun's it
seems as if Sun tries to kill such nice language as Java really is. MS, one of
Sun's main competitor on visual tools field is continualy improving speed of
their products and Sun is not able to correct such beginner bug .. I'll have to
return to VC or Visual Basic ..

Duale, he could use Qt.  Ever heard of Qt?
It runs on 12 Unixes and Windows, has all the
simplicity of Java and then some (signals/slots),
its "2D" API rocks and is blindingly fast.

I think that graphics performance in graphics environment is an essencial issue

you know what devera, i wish you'd move back
to MSVC++ so I wouldn't have to hear your whining.
Heck, if the Microsoft paradigm is so great why
did you even move to Java in the first place?!
And YES I have heard of QT.  I downloaded it,
looked at the documentation and some sample code,
and aptly deleted it.  Qt does NOT equal Swing.
They're a swing wannabe, but Qt is still
restricted by the crappiness of C++.  And because
Qt is based on something that's fundamentally
flawed, Qt is itself therefore flawed.
And again!  If Qt is so great and fast, why
are you using Java to code your GUIs???
I mean really, whatever!!  This ONE bug makes
Java impossible to use?  Gimme a break!

You know what duale,
If you don't mind me saying, you are talking through your ass.
I'd like to take this time Mr. hotmail boy to say that no one
is really interested in your verbal diarrhea and general
spouting off at people without really knowing what is being
discussed.
If you had an iq higher than a gerbal, you'd be aware of the
following:
the repaint() freeze bug:
http://developer.java.sun.com/developer/bugParade/bugs/4211948.html
the slow speed issue:
http://developer.java.sun.com/developer/bugParade/bugs/4105679.html
http://developer.java.sun.com/developer/bugParade/bugs/4123926.html
and of course the one we are in:
http://developer.java.sun.com/developer/bugParade/bugs/4185726.html
You are obviously some punk-ass kid (say 20 - 25)
who thinks his job working at the help desk qualifies
his existence in the computer _programming_ industry.
Yes that's right I _know_ you are not a programmer
by profession simply because if you did, you would
be so very aware of the problems that we are talking
about. But that's all so obvious.
So please do us all a favor, go somewhere else because
your comments are not only counter-productive, but they
are simply attacks on people.
Hotmail boy, go away please.
dreamachine

We break from our regularly scheduled flame-fests for an on-topic post:
Well, it's pretty much been established that no fix for this bug is going to
show up anytime soon, (prove me wrong, _please_!) so the only remaining
question is: Why?
I'm open to theories, and to lead off, I'll add my two-bit theory to the pile:
It's not in Sun's best interests to use hardware acceleration.
Before anyone freaks out, think about it -- all of the reasonably-priced
developments in the 2D acceleration field have been in the Wintel realm. It's
the only place where the volume and returns have justified the development
costs. By forcing all of the graphics work under Java 2 to be done on image
buffers written in Java, any advantage offered by using hardware acceleration
has been eliminated. Don't forget that Sun also sells a platform that competes
with wintel... If the java platform had a stronger foothold on the market,
eliminating hardware acceleration would be a smart move toward leveraging
market share away from Microsoft.
As a developer, I'm disappointed. The 'no modification of the java.* packages'
clause of the license agreement prevents a smart group of developers from
porting the new, working parts of the Java 2 platform out into a new JAR file.
Think of it -- applications developed under the base SDK along with this new
JAR file would be compatible with the Java 2 platform, because the 2D API is
supposed to be bakward compatible. 
Honestly -- wouldn't a version of the Java 2 platform with the
java.awt.everything packages from JDK 1.1.x be a far superior platform to Java
2? The only real stinker I've found with the Java 2 platform has been the 2D
packages -- I would love to be able to use the rest, but the current philosophy
of painting everything onto a big, slow bitmap that gets blitted to the screen
prevents me from being able to deploy anything to end users. 
Sun -- prove me wrong!

*laffs*  yeah, whatever dreammachine!
You know, the really sad part about this all is
that there _IS_ a solution.  I mean, there _IS_
a way you can draw graphics using whatever
accelerator you want, in addition to utilizing
much of what's inside of Java 2D as well.  The
sad part, of course, is that _you_ are the idiot
and cannot figure out the solution for yourself!
And I have little desire to clue you in, my
stupid friend.  If you had half a clue about
anything about programming windows or otherwise,
you would know exactly what to do.  But you're
an idiot who whines all day about this bug!!
*sheesh*  There ARE workarounds!  Crack open
some windows books and download the Java 2 
source code and maybe you'll figure out
a solution!  But I _HIGHLY_ doubt it, because
I can tell from your posts that you're an idiot!
How much money, may I ask you, are you paying
SUN for Java support?  And so do you _really_
deserve their attention?  I think NOT!  Java is
free and Java is cool!  Quit complaining!

yeah TurnerJ, it would be just so cool if some
smart developers modified java2d so that we'd
have some nice and fast graphics.  and then some
other smart developers modified 
java.util.collections so we'd have some better
collection classes.  and heck, someone else could
just go in and modify the virtual machine and
add parametric types and even multiple inheritance
too!
Yeah, that would all be so cool.  It would
absolutely destroy Java's write-once run anywhere
ideal, and probably make java the most
incompatible system in the world,
but it sure would be cool!

I've just started researching some recently
surfaced performance issues and have thus
encountered this thread.
I have some Jave code that does some graphics
and has a simple push button interface.  It has
been fine since the days of 1.0.2 and now
exhibits sluggish AWT action, "pathalogical
redisplay behavior", push it and it falls down,
blah, blah...
Observation summary:
It was fine early and was fine for a long time
until perhaps 1.1.7 or so.  Now is is broken
badly.  It should never have been broken like
this and certainly not for so long.  Symptoms
have been around for a year and a half or more.
Needs fixing now.

BUTTON ACTION SLOWDOWN DETECTED
I have detected and measured a significant
slowdown in the reaction time of the simple
AWT button.
Following is a test Java program, LagButtonTest3,
which will measure the button lag.
My results were (lag time in milliseconds):
Version Lag
1.0.2 155
1.1.5 154
1.1.8 345
1.2.2 333
In other words the "fast" VMs could manage about
7 clicks a second (frail human limited perhaps)
but the "slow" VMs are less than half as fast.
The New Java can only handle a button click (and
only a button click) once every .4 seconds.
(Tests conducted on dual 450 mhz P-III system).
Test program follows:
// LagButtonTest3 - test AWT button click lag
// Run and click button over and over again as fast as you can.......
// Prints interval count, millis between processed clicks, running average.
// August 12, 1999
// Ed Karlo
// mailto:ekarlo@ysystems.com
import java.applet.*;
import java.awt.*;
public class LagButtonTest3 {
  public static
  void main(String argv[])
  {
    LagButtonTest3Frame bframe = new LagButtonTest3Frame();
    bframe.resize(160, 65);
    bframe.show();
  }
}
class LagButtonTest3Frame extends Frame
{
  Button btn;
  int clicks = 0;
  long tm = 0, tmlast = 0, tmdiff = 0, tmdiffsum = 0;
  public LagButtonTest3Frame() {
    this.setLayout(new FlowLayout());
    this.add(btn = new Button("Click Fast"));
  }
  public boolean handleEvent(Event evt) {
    if (evt.target == btn) {
      if (evt.id == Event.ACTION_EVENT) {
        tm = System.currentTimeMillis();
        clicks++;
        if (clicks == 1) {
          System.out.println("num lag avg");
        } else {
          tmdiff = tm - tmlast;
          tmdiffsum += tmdiff;
          System.out.println((clicks - 1) + "\t" +
            tmdiff + "\t" +
            tmdiffsum / (clicks - 1));
        }
        tmlast = tm;
      }
      return true;
    }
    if (evt.id == Event.WINDOW_DESTROY) {
        if (clicks > 1)
          System.out.println("tot sum avg\t" +
            (clicks - 1) + "\t" +
            tmdiffsum + "\t" +
            tmdiffsum / (clicks - 1));
        System.exit(0);
    }
    return false;
  }
}

I'm doing some flash-type animations with the Graphics2D class, but it's VERY
slow. I will look into the possibilties of using the Java 3D API instead. 

You really shouldn't use Java3D for that. Java3D is designed for actual 3D
programs, and using it instead of Java2D will require you build a whole scene
graph, and the animation code that goes along with it. On top of that, if you
are making a applet, you need to use the plug-in and Java3D isn't
cross-platform. So far it is only availble on windows and solaris, although
ports are currently being made. But it still requires your user(s) to install
the extension, and the plug-in if needed.

With regards to 1.3, maybe the idea is to use the
new awt native interface (see /jdk1.3/include/jawt.h)
to implement a custom image paint() method.
If someone who has more Win32 drawing experience
than I manages to make this work, could you please
post and we all can move beyond 1.1?

Seems this bug is still *not* fixed in
the 1.3 beta release.
Please, SUN, DO something.
Using Java > 1.1 on the client isn't bearable
on Solaris.

Just got the latest JDC newsletter.  About Swing 1.1.1:  "This is  a
maintenance release that contains over 350 bug fixes and includes significant
performance improvements."  Thanks for not bothering to lift a finger to
the biggest bug on the list, Sun.

I've just come across something interesting, 
I'm wondering if anyone else has had the 
same experience.  I've noticed significant 
improvements in painting times in jdk 1.2.2, 
over jdk 1.2.1.  Granted, it's still too 
slow, but much faster still.  
Anyone else experience this?

2 months to go... Will SUN do something to solve
this bug WITHIN A YEAR OR NOT?  Stay tuned!
They make Microsoft look good...

I'd like to point out that using a color model 
without alpha speeds it up to NEARLY Java 1.1
levels. Nearly as in.. 80-90% of Java 1.1 speed.
Though still slower than Java 1.1, those kinds
of speeds are not catastrophical anymore. The
real problem is that Swing is implemented in Java
and as far as I know, uses a color model with
alpha which is why it's so slow in Java 2.
What i'd like to see is a Java 2 specific 
implementation of Swing which would be optimized
to work around the AWT Graphics performance
problems.

Here's Jim Graham's response to questions about this bug
in the Java2D list. This info is ***way*** more
usefull than the vage bug evaluation. Thanks Jim !
Subject: 
        Re: [JAVA2D] Hardware Acceleration
   Date: 
        Tue, 7 Sep 1999 13:23:44 -0700
   From: 
        Jim Graham <flar@bendenweyr.eng.sun.com>
    To: 
        JAVA2D-INTEREST@java.sun.com



The problems mentioned by the many comments in bug #4185726 come from a
variety of sources, including:
        1. Offscreen images - from createImage(w,h) - are not stored in VRAM
        2. Some of our blit loops are written non-optimally
           (Note that some of our blit loops blow 1.1 performance out of the
            water, though)
        3. Image scaling, as Jeannette already indicated, goes through a
           secondary buffer that slows it down dramatically
        4. More per-operation overhead than before
        5. Real alpha compositing
        6. SRC_OVER loops aren't quite as fast as 1.1.x when the image
           happens to be all opaque
The bug itself, as originally submitted, is only about the Plasma applet
which is only affected by a subset of these problems as I detail below.
Because of this, I plan to open more specific bugs for each of the above
problems (and more if I discover them) and close #4185726 as a dup of the
appropriate bugs (the ones that specifically affect Plasma's performance).
I'll announce when I do that so that people can go recast their votes
under the more specific and appropriate new bugs.
#1 is one of the primary reasons why Swing is much slower than in 1.1.x
This bug affects people with slow machines with a slow video bus more
than those with fast machines and a fast video bus (PCI is slower than
AGP 2x for instance).  Also note that the specific video driver you use
can drastically affect video bus performance (by a factor of 5x in some
cases!).
#2 is the primary reason that any image program using grayscale images
specified by an all-gray IndexColorModel are slower in 1.2+ (Note that
specifying a single non-gray color in the colormodel makes the image
draw much faster)  Programs that used color ICMs are also slower than
in 1.1.x due to poorly written indexed blit loops, but not nearly as much
as the all-gray ICMs.
#3 is the primary reason that Plasma slowed down, though if run in
non-scaled mode it also suffers from #2 (it uses an IndexColorModel).
#4 is also another major contributor to poor Swing performance
#5 is why image programs which actually use alpha are and will for the
near future be slower, but they will look way better now.  1.1.x cheated
on alpha support and we have many complaints about it.
#6 represents an inappropriate specification of ColorModel.  Always use
an opaque ColorModel when that is appropriate (though, eventually, the
performance overhead of noticing that all the alphas are opaque will drop
as CPU speed races ahead of memory speeds).
1.3 beta also has a couple of its own performance anomalies that should
be addressed by FCS:
        7. A change in compiler flags in the win32 build dropped the
           size of the dll's considerably, but cost a lot in the
           performance of some of the blit loops.
        8. Running with -Xincgc seems to improve some image code,
           noticed particularly with microbenchmarks that tickle
           image scaling.
For Kestrel:
I have revamped all of the 8-bit source blit loops already (for Kestrel
FCS) and these improvements can mean anywhere from 2x to 4x improvement
for anyone using IndexColorModel's to generate images.  I have also
added the missing loops for all-gray IndexColorModel's which results
in about a 10x performance improvement for those images on some display
depths.
Thanh also did some performance work on the alpha rendering loops.  There
was a gain in 1.3beta already (though it may be offset by the compiler flag
problem that I noted above), and there will be another gain in 1.3 FCS
(due to additional work Thanh i

Hi All,
I agree with what someone said before.  It seems hopeless to expect Sun to fix
this bug.  We all need to this problem to be fixed, so the most productive
solution might be to exchange the information each of us has gathered.  A
cooperative effort to track down the exact location in the source and fix this
bug might be the most effective course of action.

Here is a comment from Jeannette Hung, posted
to the JAVA2D mailing list:
   There are a number of reasons that drawImage in JDK1.2+ is slower than
JDK1.1.  We are trying to address some of the problems but it will not
be solved for Kestrel.  One reason is that we currently do not store the
image into hardware buffers.  That is an optimization that we still hope
to implement but have not as yet.  (It might be easier to do so when
Jim finishes the new pipeline architecture -- however that is slated for
the next major release after Kestrel.)  Another big reason is that we
are slow when we scale images.  JDK1.1 scaled images directly into
the pixmap.  We currently scale images into a BufferedImage and then
blit it so we have a lot more overhead.  Getting rid of the extra
BufferedImage will be easier with Jim's new architecture.  Another reason is
that there is a lot of verhead in our rendering pipeline (and Jim's work will
have cleaned that up).  Jim has made some of our blitting loops more
efficient (and these changes will be in Kestrel FCS) so there will be
some noticeable changes there.
Jeannette Hung

Sounds good, Jim. Lookin forward to it.

Good thing there is a sensible and detailed answer from Sun now.

Well, yeah.. We only waited for about a year or so..

I feel better now anyway...

Jim Graham gives a list of the related bugs that this one has been split into.
This is from a post to the Java2D mailing list.
Still open:
4268962 Scaled drawImage slow in 1.2 due to use of intermediate buffers
4204845 Remote use of double buffering on JDK 1.2 is very slow
4276423 drawImage of offscreen image to screen much slower in JDK 1.2
Hoping to fix for 1.3:
4276434 Opaque images produced using an ARGB ColorModel draw slowly
Fixed:
4275538 DirectColorModel.isCompatibleRaster is overly strict
4272634 compiler flags hurt the performance of some of the rendering loops
4268438 drawImage from 8-bit image to a 15/16/24/32 bit destination is slow
[Bug 4275538 doesn't sound like a performance bug but when an xRGB DCM
 rejects its own Rasters the Toolkit's ImageConsumers will then back
 off to an ARGB image to store the pixels, thus slowing down drawImage.
 The workaround is to use a pixel_size of 24 (not 32) for an xRGB DCM.]