This customer has taken the time to spell this all out, it deserves some
attention.

----------------------------------------------------------------------
Date: Tue, 28 Sep 1999 00:50:38 -0500 (CDT)
From: Todd Koeckeritz <###@###.###>
Subject: Feedback to JDK team
To: ###@###.###
MIME-Version: 1.0
Content-MD5: Ueawefu8VKcHOHgTGGE6eA==

Its unclear with the burial of bug 4185726 whether or not anyone at Sun is
truly interested in the graphics performance of Java2/JDK 1.2. I bring
this to your attention in case someone on the Solaris JDK team does indeed
care about this.

Nearly a year ago, I submitted a bug report for the terribly slow graphics
performance of then JDK 1.2betaX on my Solaris intel and Solaris SPARC
boxes. My bug report eventually got referenced to bug 4185726.

The problem that I reported is very reproducible. Take any version of JDK
1.1. Last year it was a late 1.1.6 release or early 1.1.7. Today, I ran
the same test with JDK 1.1.8_09 which I recently downloaded and installed.
Once you have the JDK 1.1 version of your choice, cd to
/usr/demo/JAVA1.2/demo/applets/Clock (yes JAVA1.2, forgot to tell you to
get your preferred production version of 1.2 installed as well). Run the
demo with "appletviewer example1.html" and note the CPU usage. I haven't
run this test as recently on my SPARC, but on my Pentium III 500 running
Solaris7, this uses about 2% of the CPU (1% for appletviewer and 1% for
Xsun). Also, when the applet runs, the appletviewer window is sized just a
little larger than the clock.

Now take your most recent production 1.2 release, I have 1.2.1_03. This is
the package that contained the demo. In order to insure I don't get any
extra classes, I run "CLASSPATH= /usr/java1.2/bin/appletviewer
example1.html" to perform the test with 1.2 as 1.1 is still the primary
installed JDK on my systems.

You should notice two striking differences between the run. The first one
is that the appletviewer window is nearly 4 times larger than the clock
itself. I haven't looked to see if this is a bug or feature. Secondly, if
you monitor your CPU, you'll see that the entire CPU is consumed by this
applet. In fact, I'm not convinved that the applet can actually keep up
with the 100 ms timer in the run method(), i.e. the paint method doesn't
complete in the 100 ms the thread actually sleeps. The breakdown in CPU
usage is 80% Xsun and 18% for appletviewer with netscape using 2% of the
CPU for who knows what.

A second example of this, I can describe, but if you need to run it for
yourselves, I'd have to give you an entire application a team of
programmers and I are writing. We have a 3D game we're working on and with
flat shading and no texture mapping, we've been able to obtain some very
good performance under JDK 1.1 at 20 frames/sec. The main screen displays
some text on the screen telling the user how to start the game and the
controls, this paints instantaneously under JDK 1.1.

Running the same code under JDK 1.2.1_03 gives a frame rate just below 5
frames/sec and the opening screen paints very slowly as you can see each
string drawn to the screen paint individually. In fact the opening screen
takes nearly a second to draw.

Quite frankly, I don't want to see any degredation of performance as I
"updgrade" to new versions of the JDK. I would accept small performance
degredations for some features, but that would be along the line of a few
percent to maybe 10 percent. Slowing the frame rate down by 75% and who
knows what the actual performance degredation on the string drawing is
simply unacceptable in this case. I expect that the frame rate descrease
is largely because we have been highly dependent on hardware acceleration
to rasterize the polygons we pass to java.awt.Graphics in the JDK 1.1
implementations. Since most of all of this appears to be done entirely
in Java in Java2/JDK1.2 and this type of function isn't what I'd call
Java's strongest point, we are likely getting killed but the all Java
implementation of the graphics context. I haven't taken the time to
do performance analysis on our code under Java2, but under 1.1 we are
spending most of our time in java.awt.Graphics.drawPolygon ().

These aren't the only places the graphics performance suffers. I can see
the performance difference in many Swing applications and nearly any other
graphics related application.

The people on the Solaris JDK team and those other developers at whatever
JavaSoft is called these days have done wonderful things for the computing
performance of Java over the years and I hope to continue to see more
improvements in these areas. I think that Java2D, when needed, is a great
addition to Java. However, I don't think that the computing performance
improvements can ever make up for an all Java implementation of the graphics
operations, giving up entirely any possibility of graphics hardware
acceleration available on the local platform and I'm not willing to give
up this performance just to have Java2D.

I sincerely hope that this doesn't fall on deaf ears as it appears to have
with the main development team at "JavaSoft." There are many developers
out here trying to do real things with Java and none of us can afford to
take this big of a step backward for any new feature.

--
Todd Koeckeritz, Euler Consulting, ###@###.### or ###@###.###

Surfin' the Web with an ActiveX enabled browser is kindof like having to
worry about getting shot everytime you knock on a door.
-----------------------------------------------------------------------------


The text problem is fixed, this bug is wrt the drawPolygon/fillPolygon operation.