Dear Sir/Madam,

I was trying to run my Java1.2 application (with a lot of graphics
painting/drawing) on my new SGI Visual 320 but found the application was
extremely slow, sometimes even halted some other background jobs.  The same
program ran smoothly on a less powerful Windows NT4.0 PC equipped with only
Pentium II 266MHz machine and a weaker graphical adaptor.  I showed the
problem to local SGI engineer and asked them to try the demo program (e.g.
the jdk1.2/demo/Applet/Animator/example4.html) which come with the Java1.2
package downloaded from SUN  customer , of course) but they found the similar
symptoms.  Even worse, the applet run backward from the bottom instead from 
the top.

SGI engineers found out that the Sun's Jdk1.2 has a hardware-dependent
bug that restrict the applets (i.e. animator/example4.html) from running
normally in 16bit or 32bit color mode.
They told me that the workaround is to run the applet in 8 bit mode (while the applet is
running, one may switch the color mode back to 32 bit after the applet is launched. 
As suggested, I tried to lower my display to 256 color mode for the Java1.2 applet
demo (i.e.
the jdk1.2/demo/Applet/Animator/example4.html).  I must admit that I see some
improvement, the animation sequence doesn't run backward from the bottom as
before.  However, when I drag the windows within the desktop, very serious
"shadows" behind the moving window appears and the screen blinks in an
unacceptable fashion.  I then tried to reset my Cobalt back to true color mode
after I launch the applet but it doesn't help much.  This work around is not very
successful.  Even if this "cheating" works for this simple applet, I doubt it will
work for more complicated application, such as those which allows the users to
launch another graphical application/applet thread in the middle of the program.
(My own Java1.2 applications are full of these kind of operations.)

I was also told by the local SGI consultant that there is some incompatability between the
SGI Cobalt chip set with the Sun Java1.2.  But I would like to point out that I have
run the same Java1.2 demo applet on many other less powerful machines with less
powerful graphical chipsets (such as (i) ACER Pentium II 266MHz WindowsNT4.0/95
Matrox Millenium G200 4MB Video RAM; (ii) ACER Pentium II 300MHz Windows/95 ATI
RangePro 2MB Video RAM) but everything is absolutely normal.    He even told me
that SGI engineers found that some low level graphical instructions such as RGBX
becomes XBGR in the cobalt chipset.  I wonder if SUN has made great change regarding these
low level instructions from jdk1.1.4 to jdk1.2.  As a matter of 
fact, everything is normal when I ran the same program on the same
machine but using the jdk1.1.4 version.

I discussed the above phenomenon to my other colleagues and they are VERY
DISAPPOINTED with jdk1.2 in this respect.   I should be grateful if
you could provide me solution to this problem as soon as possible.

Thanks you very much.

P.W. Li
(Review ID: 57933) 
======================================================================




Hi,

I think I have found a bug running Java 1.2.1 on SGI Visual 
Workstation 320. This is probably the same bug as #4236332
but I'll provide you with some additional information. 

When running a Java standard demo on my SGI NT machine (e.g. the 
Notepad demo), the GUI is acting strangely. Redrawing of the
window is very slow. If you for example occlude it by another 
window, it starts blinking and there is occasionly a severe 
color defect (parts of the window turn yellow). 
Also, the fonts look strange and in some demos hardly readable.

I.m running in 1280x1024, True color mode, using the latest 
patches from SGI: sgicobaltgfx402.

When trying to run our commersial, java-based application, 
containing several java(swing)-windows, it seems that every window gets re-draw 
events whenever one window is occluded. Sometimes it even seems
to loop through redraw-events several times. 

In order to plan our releases, could you please let me know 
if this is considered to be a bug, and if so, your time-plan 
for a fix.

Best Regards

/Peter Larsson 
M.Sc. Software Engineer, Opticore AB
(Review ID: 58104)
======================================================================




Our commercial application is 2D-3D interactive CAD  system written in Java2. 
The performance is  customer  on usual PC. But it is too slow on SGI Visual Workstation,espectially when
drawing 2D drawing, selecting the element of geometry, and selecting the button consist of Swing. 
Maybe 20 times slower.

Hardware: SGI Visal Workstation 320
               Cobalt Graphics Driver 4.1.1 ( or 4.0.2)
               True Color mode(or 32768 )  
Software:  WindowsNT4.0
                JDK1.2.1 or JRE 1.2.1
Application:Java application(2D,3D CAD)
(Review ID: 93506)
======================================================================




Cannot use True Color on SGI's Visual Workstation!
If true color was used, java2d corrupts color map and slows down all java program using java2d.

How to produce the bug.

1-1) Purchase SGI's Visual Workstation.
1-2) Use java2D in jdk1.2 or jdk1.3beta.
(Review ID: 95384)
======================================================================

When setting up 8 bit color mode on Visual Workstation, the performance makes better. But in this case
the application couldn't draw true color image.
(Review ID: 93506)
======================================================================




use 8-bit color mode.
(Review ID: 95384)
======================================================================

I do not believe that the described problem is confined to AppletViewer.  I'm
guessing that this is either a hardware problem or a problem with changes in 
JDK1.2 due to the addition of 2D.  Routing to 2D for their evaluation.

  xxxxx@xxxxx   1999-05-10

Missing RGBX loops.

  xxxxx@xxxxx   1999-05-28

We have contacted SGI for some hardware to reproduce this problem and are
awaiting receipt of that machine.

  xxxxx@xxxxx   2000-02-03

=====================================

There's a few problems here:
- The rendering loops for the offscreen surfaces are the most generic loops,
but those generic loops assume a color model type (i.e., Xrgb
for the 32-bit case).  Our most generic renderers should instead consider the
color mask of the given surface type and use that mask when coloring
the pixels of the primitives.  This should fix the problems with the incorrect
colors being displayed.
- We do not currently support any Blit acceleration for surfaces with this color
model (e.g., Rgbx in 32-bit mode).  So instead of going through the relatively
fast IntIsomorphicCopy Blit routine (which would actually work fine for 
the 32-bit case, as we don't care how the int's are structured, but only
that they are structured the same in the src and dest surfaces) we find
ourselves in the most general Blit routine which has to do color lookups for
every pixel.  This is the source of the performance bottleneck.
- The onscreen surface is currently being misclassified as Xrgb (in the
32-bit case).  Fixing the two problems above will necessitate getting the
onscreen classification correct so that we get into the correct (and fast)
Blit routines.
- The above problems are for the 32-bit case only.  I expect similar problems
with colormodel masks in the 16-bit case, but I'll know more once
I fix the problems above and investigate the other bit-depths.

  xxxxx@xxxxx   2000-02-18

The problems and solutions were pretty much as described above.  Many Blit
loops and new surface types were added to handle the modified rgb configuration
of the SGI 32 and 16 bit cases.  Performance has gone up dramatically and
should now be pretty reasonable.

Note that these fixes were implemented only in the Merlin (jdk 1.4) workspace.

  xxxxx@xxxxx   2000-03-01

I too have seen the same problems, and one additional.
Java3D seems to stretch all images in the X direction.
I'd have to guess that they're picking up an incorrect
screen size and consequently getting a bad aspect
ratio.  I'll send a note to the Java3D list as well.
--
Allen McPherson
Los Alamos

Due to this bug, I am stopping work on a Java
app and converting it to C++/MFC. I have no
choice since it must run on the SGI. Help!

With 1.2.2 on an SGI 540, fonts come out very jaggy and the speed is terrible.
Setting JAVA2D_USEPLATFORMFONT to true solves the problem.

The SGI/NT 540 has the potential to be able to
offset Java performance troubles, especially on
imaging aps like ours based on JAI (Java Advanced
Imaging API).  But until Sun fixes this bug, 
our 3 540's are doorstops and management is 
questioning our JAI approach, because they cannot
see our imaging prototype running fast enough.

Still broken with 1.3 beta.  Horribly slow as well on a dual Xeon NT machine.
Ick!

The slow performance seen on Java 1.2 is also
seen on Java 2.0.  I don't believe it is even a pixel image format as
the whole Java application is slow in performance
when running in True Color.  It maybe the that Java
Image class must convert from RGBX to XRGB but on Java 2
even though it can be devloper selectable, the whole Java
window performance is still slow overall in True Color.

The same problem occured when using JDK 1.2 with Windows NT 4.0 SP 5. It
disappeard
when using Windows 95 JDK 1.2. My application normally uses the standard
interface of 
java.awt.Graphics. The performance on Windows 95 goes down, too, when drawing
text 
with the features of Graphics 2D (using rotation of any angle on some text
strings).

Using JDK 1.3 pre final the problem disappears on Windows NT 4.0.

Will this fix be included in jdk1.3 release?

Since Merlin (jdk 1.4) will not be out for at least 6 months, can 
you provide a fix for jdk 1.3?

To have a fix for jdk 1.3 will be VERY VERY helpful.
Without it it almost impossible to use java on SGI 320.

BTW, how come that this bug is closed but NOT fixed?

These work arounds are unacceptable.  We are working with 
Intralink and ProE and there do not work properly in 8 bit 
color. 

Comments on the last couple of posts:
The bug is fixed, not just closed.  The fix was implemented
in jdk1.4 (currently shipping Beta3).  There is no current
plan to back-port the fix to jdk1.3.
As for any users requiring things to work on existing
applications, we would suggest trying jdk1.4; it should
do the trick (either in the Beta version (for now) or the
full release version (due in the next couple/few months).

Chet.
Java2D team

Sorry, forgot to mention we're running the sgi 1600 flat 
panels with the sgi320 NT workstations (around 20 
stations). Now that I've vented, are there any customizable 
java settings we could try?

We agree with jgreenberg. We have loaded the 1.4 beta3 and 
continue to have degrading issues with sgi320 running PTC 
Intralink 3. Window actions like minimizing,toggling 
between browsers and changing WS frames cause the cpu to 
peg. Minutes pass by waiting for the screen change and the 
cpu to release. Another sore spot is the Locate window. The 
operator section is a black dot that can't be read. This 
java issue is preventing us from advancing and we're fast 
approaching a position of running unsupported software.

The problems mentioned in connection with ProE and Intralink
are not the same problem as the original bug (and are
thus not fixed by this bug fix).  It's not clear to me from
these short descriptions what the problems are that you are
having.  Could someone please submit a new bug against this
problem and include:
- a clear description of the various issues, especially
as seen in jdk1.4.
- a testcase.  If possible, please submit a test that does
not involve these applications as we do not have them in-
house.  If not possible, describe exactly how to reproduce
the problem in these apps.
- You might also try submitting this bug against the apps
in question (i.e., with those other companies); that 
might make it easier for us to get the information we
need (if those companies correspond with us on the problems)

Thanks,
Chet. (Java2D)

Also, please try running the applications with tracing and
send a copy of the output to java2d-comments@java.sun.com. 
You can enable tracing with the command:

java -Dsun.java2d.trace=count ...

(Forgot to mention - the tracing mechanism is only available
on 1.4beta3 and later releases...)

The point of jeellis' comment on 14-Dec-01 (re problems
with PTC Intralink 3) is that the suggestion to use
JDK 1.4 as a workaround to this bug is not viable.  JDK 1.4
produces too many other problems with PTC Intralink.