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".
