Bug ID: JDK-4731131 App crash drawing lines after display mode switch (windows/GeForce2Go chip only)

Type: Bug
Component: client-libs
Sub-Component: 2d
Affected Version: 1.4.1

Priority: P4
Status: Resolved
Resolution: Fixed
OS: windows_nt
CPU: x86

Submitted: 2002-08-13
Updated: 2002-12-17
Resolved: 2002-11-12

Other	Other
1.4.1_02 02Fixed	1.4.2Fixed

Run notepad (java -jar Notepad.jar in demo/jfc/Notepad).  Now bring up
a DOS box.  Hit Alt-Enter (this puts the DOS box into fullscreen mode).
hit alt-Enter again (this puts the DOS box back to normal).

On my laptop (Toshiba Satellite 2805-s402 with an nVidia GeForce2 GO chip),
this causes notepad to crash with an error inside of Direct3D.

The priority is currently set to 4 because I do not know of other systems
with this problem (including desktops with GeForce2 cards), so presumably
this is a bug with the nVidia chip/driver.  If there
are other configurations with this problem, the priority should be increased.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_02 mantis FIXED IN: 1.4.1_02 mantis INTEGRATED IN: 1.4.1_02 mantis mantis-b07

14-06-2004

EVALUATION There are a couple of contributing factors to this problem: - We do not not get any error when calling BeginScene() on the d3d device for the back buffer. - Without any error on BeginScene(), we proceed immediately to call DrawPrimitive(), which ends up crashing inside of d3d (either the runtime or the driver) with a null pointer exception. The first problem above is not the full problem, however: if we force a Restore() at this point on the surface, we still crash in the next call to d3d. In fact, this is what appears to be happening inside of Direct3D; through the debug messages spewing into the DevStudio debug console, it appears as though BeginScene() actually forces a surface restore instead of returning an error. So it appears that the problem is not that we do not know to restore the surface, but that the restoration does not help any and there is something unworkable with d3d in this situation. in fact, you can recreate the problem completely outside of Java; simply run a DirectX6 d3d demo and do the same DOS box trick; you'll see a very similar crash. I did this with Tutorials/DrawPrims in the dx6 sdk. An interesting point to note is that the DX7 version of the app does not crash. The behavior is quite different: - BeginScene() returns an error in DX7 - Restoring the surface(s) in DX7 does whatever it is supposed to to make d3d function correctly on the surfaces so that the next time d3d is called there is no error. There appear to be a couple of options worth pursuing to find a workaround for what seems to be a driver/chip problem: - Use the DX7 interfaces. Currently, we use DX3 interfaces for DirectDraw and DX5 interfaces for Direct3D. This was done because we are not using any advanced functionality in either API, so we default to the lowest common denominator so as to not preclude acceleration on any systems that do not have later versions of DirectX (for example, win98 ships with DX5). But we could optionally look for and use DX7 if it is available. Since the crash I am seeing is on Windows2000 and this OS ships with DX7, this would presumably fix the problem I am seeing. Simply switching interfaces is not completely straightforward, since the API changed somewhat as of DX7, so we would need to change how we do several things (mostly related to Direct3D). - We could catch the exception and do something intelligent with it. I experimented a bit with this and found: - an exception caught after BeginScene() is called should ensure that EndScene() is also called or else no further d3d operations on that surface will succeed. - I got things to basically work with the Notepad crash by forcing a displayChange propagation. However, there were some artifacts on the buffer after the repaint completed due to the unsuccessful drawing of the lines that caused the exception. Also, this approach did not work for fullscreen crashes (such as DrawLineTest) because the displayChange propagation did not recreate the surfaces necessary to stop the error, so the exception was simply caught over and over without the problem being fixed. Given the time that a real fix would take, the (hopefully) niche effect of this bug (only on my laptop system), and the assumption that this is a driver bug that we could only work around and not actually fix, I'm putting it on the shelf for now. ###@###.### 2002-08-13 Actually, I am putting a small workaround in the code that will at least punt on d3d operations on the problem surface. I now trap the exception when it is thrown in native code and, instead of crashing, I disable d3d on that surface to avoid further exceptions on the surface. Another possible approach is to recreate the problem surface; I prototyped this approach and it should work but there are details to it that I do not have time to tie down, so I'll just putback the don't-crash workaround for now. ###@###.### 2002-08-23 See bug 4736213 for more information on this problem: another side effect of the ineffective restoration of surfaces that happens in calling d3d's BeginScene() method is that all of our offscreen surfaces are restored without our knowledge, so we never get the message that we are supposed to restore the contents. This results in black or garbled icons (for example) in Swing apps, even with the workaround that I am putting in the code now; by the time we have caught the exception that is thrown in d3d, it is too late and our surfaces have all been restored for us. One possible fix for the surface restoration is to trap errors like this and propagate a message to all offscreen surfaces that they need to be recreated. ###@###.### 2002-08-23

23-08-2002