43662 - Turn off the DirectDraw support for Java applets!!!

Status: RESOLVED WONTFIX

Description

[William C. McCain]

From Bugzilla Helper:
User-Agent: Mozilla/4.73 [en] (Win98; I)
BuildID:    2000061311

PLEASE change the support for Java applets so that it does NOT use DirectDraw.  
Several bugs have been reported to Sun regarding the DirectDraw support that 
they put into Java 2 (1.2 and 1.3).  The basic problem is "garbage graphics" due 
to out-of-sequence execution of graphics primitives when DirectDraw is enabled. 
 This only happens when using recent-model high-end display adapters that 
actually implement DirectDraw (which is intended for VIDEO GAMES).  Two examples 
of popular video cards that are known to exhibit this problem are ATI Rage Fury 
and 3dfx Voodoo3.

With Sun's "appletviewer" is is possible to bypass this problem by using the 
"-J-Dsun.java2d.noddraw=true" flag, which "turns off" the DirectDraw support.  
When this is done, all applets work correctly on all video cards.  
Unfortunately, there is currently no way to turn off the DirectDraw support in 
Mozilla.  To avoid SEVERE compatibility problems, the DirectDraw support should 
be OFF by default.  If it is desirable to support DirectDraw at all (which, in 
my opinion, is highly questionable), then it should be user-enabled via a 
"Preferences" option.

There are two bug reports on Sun's Java developer Web site that show good 
examples of this problem.  One report, 4314208, regards the JTable demo in 
"SwingSet2" (a sample applet that ships with Java 2).  Scrolling of the JTable 
demo fails badly under either Mozilla or Sun's "appletviewer" (when using either 
of the aforementioned video cards with DirectDraw enabled).  The other report, 
4337823, includes a sample applet that utilizes two very simple AWT primitives 
(no Swing at all) to exhibit the same bug.

The fundamental problem with the DirectDraw support in Java 2 appears to be the 
fact that it is not a complete re-code that utilizes DirectDraw for EVERYTHING. 
 That is, some graphics primitives were re-coded to use DirectDraw while others 
still utilize the standard Windows GDI API.  Consequently, primitives are 
sometimes executed out-of-sequence, because (under some circumstances) a later 
primitive that utilizes DirectDraw can be executed BEFORE the GDI queue is 
flushed!


Reproducible: Always
Steps to Reproduce:
1. Install an ATI Rage Fury or 3dfx Voodoo3 display adapter.
2. Under Mozilla, run the "SwingSet2" applet (included in Sun's Java 2 SDKs).
3. Click on the "JTable" demo button in the "SwingSet2" applet.
4. Scroll the table of small cells that appears in the "JTable" demo.
   --- OR ---
2. Go to http://developer.java.sun.com/developer/bugParade/index.jshtml and 
access bug report number 4337823.
3. Copy the "fonts" applet from this bug report and compile it under any Sun JDK 
(1.1, 1.2, or 1.3).
4. Run the "fonts" applet under Mozilla.
5. Press the "Scroll Lock" key a few times and observe the results.

Actual Results:  In the "SwingSet2" applet, the "JTable" cells become trashed 
when they are scrolled.

In the "fonts" applet, random character cells appear blank (instead of showing a 
single text character) each time the applet repaints its "canvas" (whenever the 
"Scroll Lock" key is pressed).

Expected Results:  In the "SwingSet2" applet, the "JTable" cells should stay the 
same when they are scrolled.

In the "fonts" applet, a text character should always appear in each character 
cell (except those that normally display a "space", such as 0x20 and 0xA0).

Comment 1

[edburns]

Stanley's field.

Comment 2

[Asa Dotzler [:asa]]

sounds like a bug in Sun's DirectDraw support not Mozilla.

Comment 3

[William C. McCain]

Quite right!  Sun's DirectDraw support is buggy, and Mozilla will suffer as a 
result ... unless you do the smart thing and bypass (turn off) the DirectDraw 
support.  Sun's appletviewer has an option to do just that, and since Mozilla's 
applet code appears to be based on Sun's code, it should be very easy for you to 
turn off DirectDraw.

I don't think it is likely that Sun will FIX the DirectDraw support anytime 
soon.  Indeed, I suspect it may not be POSSIBLE to make it work correctly -- it 
may have been a fundamental design blunder to even TRY to use DirectDraw!  That 
is because the bug is related to the fact that the Windows platform executes 
DirectDraw primitives immediately, but GDI primitives are QUEUED.  That very 
likely makes the mixing of DD and GDI, as Sun did in Java 2 for Windows, a BIG 
NO NO -- because they can never be fully synchronized.  You either have to use 
DirectDraw for EVERYTHING (as video games do) or NOT AT ALL.

And it's not like it's hard to show that it breaks.  Sun's own sample applet, 
SwingSet2, JTable demo, displays severe problems when run on a wide variety of 
current display adapters (from ATI, Matrox, and Voodoo)!  See Sun's Java bug 
report 4314208 for lots of gory details.

You can always turn the DirectDraw support back on, when and if Sun actually 
manages to make it work ...

Comment 4

[Asa Dotzler [:asa]]

removing self from cc:  

Comment 5

[stanley.ho]

DirectDraw may be disabled in Netscape 6 by putting -Dsun.java2d.noddraw=true 
in the Java Plug-in Control Panel's Runtime Parameter. 

Comment 6

[edburns]

------- Additional Comments From [e-mail] 2000-09-07 01:47 -------

DirectDraw may be disabled in Netscape 6 by putting -Dsun.java2d.noddraw=true 
in the Java Plug-in Control Panel's Runtime Parameter.