Here is a list of bugs that represent specific performance problems with drawImage. These bugs represent most, hopefully all, of the problems that developers have been experiencing that used to be tracked under the single umbrella bug 4185726. The problem with bug 4185726 was that it became the anonymous clearing house for any possible complaint about graphics performance to such an extent that we really had no decent way to know if we were tracking everything that was causing concern for the developers. We also had no good way to provide feedback on a case by case basis. Since we've closed 4185726 as a duplicate of the bug describing the only remaining specific problem that it was originally submitted about, it is important for developers here to look at the list below and see if the concerns they had for the performance of drawImage are represented. If your concerns aren't represented, then a new bug dealing with those concerns needs to be opened so that we can investigate it, otherwise we might not have ever known about the problem you were seeing. [ Side note: If we had caught it soon enough, we could have simply reworded 4185726 to be that new bug, but unfortunately the time when that was appropriate has long since passed and too many unrelated problems were being attributed to that one bug. I apologize for dropping the ball there. In order to get a clear picture of what problems people are really having and in order to provide more specific feedback about those problems, it is important for us to be able to distinguish the complaints and to divide and conquer them (both in feedback and in fixing the problem). ] 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.] ...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".