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 is doing on the loops and maybe also from
fixing the compiler flags). This will primarily affect alpha blended
images and antialiased rendering.
For Post-Kestrel:
There is a new architecture that helps with a lot of problems, but it
will not be going in for Kestrel. The features are:
- Much less overhead for "draw, setColor, draw, setColor, ..."
(helps with Swing a lot - #4)
- Abstracted rendering destinations to allow integration of VRAM
based image rasters
- More flexible ways to characterize blit loops to allow us to
target common operations better and to allow existing loops
to be used by a variety of similar destinations, reducing
code size and ensuring greater coverage of existing loops
(to avoid, for instance, the all-gray ICM problem I had to
fix above)
...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".
