This is a bug to list some of the performance issues Java2D/Swing
applications have when running on SunRays.

Swing uses double buffering, and we (Java2D group) have
made special optimizations for remote X server case by
using pixmaps for storing offscreen images (like a
backbuffer, or sprites).
It worked out really well for a 'regular' remote X display case,
but it doesn't do well due to performance of blits from pixmaps to
screen on SunRays.

I've attached the results from one of our benchmarks (J2DBench),
which measures performance of some 2D operations, running
on our latest released version of jdk - Merlin (1.4, build 92).

Unzip the archive, and check out the sunray_vs_remotex.html file.
It shows the comparison between running the J2DBench test
when displaying to a SunRay appliance versus 'normal' remote X,
running from a sunray server and displaying to a Solaris 8 Ultra 60
with ffb2+ framebuffer. As far as I know, both networks are 100mb,
so this is a somewhat accurate comparison.

Note that text and shapes rendering is considerably worse,
as well as some of the drawImage cases (unfortunately,
the ones most used by SwingApplicaton - opaque blits w/o scaling,
which are accelerated through the use of Pixmaps in normal remote X
case).

The reason scaling or blending operations are faster
on SunRays is that apparently the pixmaps are stored on
the X server which runs on the same machine as the application,
and these operations can't be accelerated using X as it
doesn't support scaling or alpha blending.

Some other applications which can be used to assess
Swing performance is SwingSet2 demo (can be found in
any j2sdk distribution in <j2sdk location>/demo/jfc/SwingSet2).
Note that scrolling is way worse than in normal remote X case.

To make sure it's not our implementation is slowing
us down, I've performed some tests using x11perf
(a standard native X11 benchmark application)

Here are some results showing that the
performance of pixmap->screen blits on SunRay is less
than stellar.

Case 1: SunRayS->SunRayTerm -
        normal SunRay operation: display from SunRay
server to the SunRay terminal
Case 2: Remote X Display -
        a 'normal' remote display from (the same) server
to a remote X display on my machine
Case 3: Local X Display -
        Local X display on my machine (Ultra 60 + ffb2+).

The results (we have 100mb SunRay network here):
      -copypixwin500 -shmput500 -putimage500 -copywinwin500
Case 1 55.3/sec 66.1/sec 28.4/sec 212.0/sec
Case 2 551.0/sec N/A(no shm) 41.4/sec 95.7/sec
Case 3 555.0/sec 548.0/sec 106.0/sec 96.4/sec

-copypixwin500: x11perf parameter which measures copies from
pixmap to the screen
-shmput500 : x11perf parameter which measures copies to the
                screen using XShmPutImage (local display only)
-putimage500 : XPutImage performance

As you can see, copying from pixmaps to the screen much slower
than in 'normal' remote X case - sometimes 5-10 times slower.

The surprising result is that copying from window to window
is faster on a SunRay than on my ffb2+ framebuffer.
So I guess it's possible to write a fast-scrolling (only)
application by sacrificing the double-buffering.

Copying from pixmap to pixmap is about the same for all cases.

As you can see not using the pixmaps to hold the back-buffer
won't help much, since we need to get the backbuffer to the
screen anyway, and XPutImage is slow too.

The rest of rendering primitives is also much slower than
'normal' remote case:
             -rect100 -triangle100 ..etc
Case 1: 15400.0/sec 1350.0/sec
Case 2: 57500.0/sec 17300.0/sec
Case 3: 61500.0/sec 17900.0/sec

The rest of primitives show similar results (5-10 times
slowdown when compared to a regular remote X display)

Because of this as well as a bunch of other reasons Swing can't
use single-buffered rendering strategy.


So to sum it up - we'd really like to see these
performance issues addressed asap. We're hard pressed to make
Java2d/Swing run fast on SunRay (at least be comparable to a
remote X server case), but we can do only as fast as
XServer+SunRay architecture allows us.


###@###.### 2002-03-05