EVALUATION

I will include the Evaluation from bug 4276423, since most of that
information is about the performance of small images:

I recently got the following results on my PIII-dual 866 NT4 system (video
card ATI Rage Pro Turbo), at 32 bits per pixel:

jdk1.1:
	20x20 		16,909,090 pps
	100x100		22,268,000 pps
	300x300		24,488,304 pps
jdk1.2:
	20x20		9,440,362 pps
	100x100		21,333,600 pps
	300x300 	24,570,419 pps

jdk1.3:
	20x20		9,106,579 pps
	100x100		21,231,683 pps
	300x300		24,616,363 pps

jdk1.4 (my most recent build):
	20x20		7,495,593
	100x100		22,236,607
	300x300		23,695,652

And on my PIII-500 (single CPU) win98 system with a Matrox G400 running
32 bits per pixel:

jdk1.1:
	20x20		37,724,773
	100x100		36,661,107
	300x300		36,808,163

jdk1.2:
	20x20		3,631,375
	100x100		31,629,213
	300x300		43,824,489
jdk1.3:
	20x20		3,728,680
	100x100		33,635,275
	300x300		42,096,774

jdk1.4:
	20x20		5,750,953
	100x100		108.602,065
	300x300		165,263,578

From these results, it looks like:
	- There are definitely differences between OS's and video cards,
	especially when we are comparing hardware-accelerated images and non-
	accelerated images.

	- The overhead of the small (20x20) images appears to drag down the
	performance of 1.4 offscreen images to nearly the level of the
	1.2/1.3 software-based images.  In fact, on the older ATI video
	card, the hw-based images were even slower than the software-based
	images.

	- NT performance of all images seems gated at some maximum amount.  This
	might be a restriction on NT, or it could be a constraint of the
	older video card.  More investigation would be necessary to figure
	it out.  But all larger image sizes on all releases seem about the
	same.

	- win98 shows the difference between jdk1.1 hw-based images
	(flying at about 36M pps) versus jdk1.2/1.2 sw-based images
	(limited to only about 3M on the smallest image).

	- win98 on this fast video card shows the advantage to directDraw
	in the latest jdk1.4 builds; performance of jdk1.1 was gated
	about around 36M pps, but the performance of DirectDraw-based images
	appears much higher, at around 165M pps for th largest image size.

more work is necessary.  We need to make sure that we eliminate any overhead
that might be contributing to the lower scores in jdk1.4 for small image
sizes.  Profiling is necessary...

chet.haase@Eng 2001-04-24

I did a little more debugging/profiling and got the following information:

One of the key pieces of overhead in our Blt processing is due to the
ddraw Clipper object.  When I eliminate the Clipper (i.e., I don't attach
it to the window or set the clipper on the primary), then I more than double 
the performance of the smalles (20x20) image copies.  On my test system
(PIII-866 dual processor, nVidia TNT2), this made the performance go from
11 M pixels per second to over 26 M pixels per second.

Of course, this is a bottleneck that we cannot do much about: drawing
without a Clipper object requires that we do our own clipping to the
window (not too hard) but it also means that we would be subject to
Windows events that could cause rendering artifacts.  For example, if 
our window was obstructed, we would do our Blts over any overlapping
windows, regardless of which window was supposed to be on top (ddraw
draws directly to the screen without regard for Window properties).
And even if our window was on top at the time we issued the Blt call, 
this might not prevent some event (such as the user dragging a window)
from overlapping the window at the time of the the actual Blt operation
(there is a delay between our issuing the call and that call actually
being processed by the hardware).  Actually, this situation might be
handled for us through context switching mechanisms of the driver/hardware
(hopefully the hardware would flush the graphics pipe before allowing the
window system to move things around).  But there is still a small hole of
opportunity between our checking for obstruction and actually issuing the call.

Anyway, this got our performance up to 26 M pixels per second.  But the jdk1.1
version is still at 44 M, nearly twice the performance of our non-clipped
jdk1.4 version.  I think this difference can be attributed to various
overhead elements in our drawImage() processing.  During a profiling run
(using Compuware's TrueTime product), I found that we are spending
significant amounts of time (on the order of one to five percent) in the
following routines:
	ClipInfo (used to derive the actual src/dst values after clipping
		against sg.getCompBounds()
	Blit.getFromCache() (gets the cache entry for our Blit call)
	DrawImage.blitSurfaceData (spends a couple of percent just dealing
		with setting the CompositeType)
	AcceleratedOffScreenImage.getSourceSurfaceData (gets the accelerated
		surfaceData object for accelerated images)

There are various other methods and simple operations which end up taking
over a percent of the runtime.  Many of these functions are very simple
(like the equals() comparison when retrieving the Blit from the cache), but
when called over 60000 times (in this case), they add up to significant
overhead.

The reason for performance loss due to overhead in this case is that the
primitives in question are so small (20x20) that the more we do between
issuing the call from the application and actually issuing the ddraw call,
the more we suffer from each intermediate step.  For the larger primitives,
the amount of overhead is now insignificant compared to the performance
time of the actual rendering so we see the performance benefits of
ddraw much more clearly.

(End of Evaluation text from 4276423)

More info from further analysis:

I wrote a native app that tested similar image copies using ddraw and
GDI images.  It varied the size of the images and performed three tests
with each size: ddraw without a Clipper, ddraw tih a Clipper, and GDI
compatible bitmap.  These tests were chosen to represent jdk 1.4
(ddraw with a Clipper), jdk 1.4 maximum possible (ddraw without a 
Clipper - not necessarily something we can do, but a nice theoretical
maximum to know about), and jdk 1.1 (they used compatible bitmaps for the
offscreen images in that release).

The numbers I got were interesting.  It turns out that GDI performs 
significantly better than ddraw w/o Clipper up to a size of about 32x32.
It performs better than ddraw with a Clipper (i.e., a comparison of
jdk1.1 and jdk1.4) up to a size of about 47x47.  After these values,
GDI drops significantly and ddraw is able to achieve much better 
performance results both with and without the Clipper after those points.

In fact, GDI hits a limit of about 65 Million pixels per second, but
ddraw is about to achieve over 200 million pixels per second with larger
primitives.

This data tells me that our performance bottleneck may not be due to
our overhead in getting to the ddraw call but night, instead, be due to
simple GDI performance advantages for smaller primitives.


chet.haase@Eng 2001-07-18