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).
Assignee: edburns → stanley.ho
Component: Java APIs to WebShell → OJI
sounds like a bug in Sun's DirectDraw support not Mozilla.
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 ...
removing self from cc:
DirectDraw may be disabled in Netscape 6 by putting -Dsun.java2d.noddraw=true in the Java Plug-in Control Panel's Runtime Parameter.
Target Milestone: --- → Future
------- Additional Comments From email@example.com 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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.