SUGGESTED FIX
------- ddrawUtils.cpp -------
*** /tmp/sccs.ppaq4N Mon Jun 10 15:18:47 2002
--- ddrawUtils.cpp Mon Jun 10 15:13:08 2002
***************
*** 499,505 ****
if (tmpDdInstance->hwndFullScreen == NULL) {
AwtWin32GraphicsDevice::DisableOffscreenAccelerationForDevice(
tmpDdInstance->hMonitor);
! ReleaseDDInstance(tmpDdInstance);
}
return FALSE;
}
--- 499,507 ----
if (tmpDdInstance->hwndFullScreen == NULL) {
AwtWin32GraphicsDevice::DisableOffscreenAccelerationForDevice(
tmpDdInstance->hMonitor);
! // 4636548: Do not release the DDInstance because the loss of
! // the primary surface may be only temporary due to another app
! // entering fullscreen mode (such as a screensaver).
}
return FALSE;
}
|
EVALUATION
Commit to fix in mantis (crash).
###@###.### 2002-02-12
The attached screensaver is a binary only file. In order to debug this problem, we need the source code.
###@###.### 2002-05-02
I believe the author is ###@###.###. Write him, maybe he will agree to give you the sources. Company's web page is http://3dscr.com.
###@###.### 2002-05-03
I discovered several easy ways to reproduce this problem. Run a simple java application (such as FullScreen/CapabilitiesTest) using 1.4 or later and then launch a second fullscreen app. The first app will crash. This is a nasty bug that will crash *any* java app simply whenever a Windows 2000 app is launched (such as a screensaver). I'm raising the priority and have updated the suggested fix.
###@###.### 2002-06-10
Handing over to Java2D.
###@###.### 2002-06-12
Looks like the failure to create the primary comes from certain situations in
which we receive a ddraw error. For example, when there is another DirectX
app running in fullscreen mode, then we tend to get the error
DDERR_NOEXCLUSIVEMODE, which indicates that we cannot create a primary
surface when another application has exclusive mode access to the screen.
Interestingly, this problem seems specific to DirectX apps; presumably
OpenGL apps have another mechanism for accessing fullscreen that does
not conflict with our direct draw code.
The suggested fix is probably correct, although we may want to go farther.
At the very least, we do not want to delete one of the ddInstance[] devices
just because we failed to allocate a ddraw primary surface for that
device at a particular time; deleting the ddInstance object is a one-way
operation in the current code and we will not be able to accelerate future
operations during this runtime. Of course, this operation also causes a
later crash, but even were we to fix the crash bug we still do not want to
disable acceleration simply because we were running in the background while
a fullscreen app took over the machine.
We also want to make sure we do not disable acceleration for offscreen surfaces,
which is something else that happens in the current code upon primary
creation failure.
Although the effects of this bug are severe (crashed application), the fact
that it takes outside stimulus to cause the crash (DirectX app running
fullscreen) should be taken into account. I'm downgrading this to a P2.
###@###.### 2002-06-13
Note that the fix for the crash shows up color/sizing problems in the
application (See bug 4702062 for more information, but I am closing that
bug as a duplicate of this one since they are all caused by the same
base problem).
###@###.### 2002-06-18
I don't want to disappoint you guys, but there is no change of this ugly behaviour in the latest RC build of Merlin #16. Is it supposed to be fixed there ?
###@###.### 2002-07-08
The crash reported in this last comment is not related to the bug fix; I was
only able to reproduce this last crash by running on the exact same video
card (Matrox G400 dual head) with the same (old) driver version; running
on the latest drivers for that equipment appears to fix the problem.
So this last report appears to be a driver version bug that is fixed by
upgrading the driver, not by anything related to Java.
###@###.### 2002-08-19
I have opened up a new bug against this old-driver problem: 4738111. In
general, we require use of the latest display drivers and it is not possible to
work around all display driver bugs. However, we should at least figure out
why we are crashing and work around it if at all possible.
###@###.### 2002-08-30
I am very happy to say, that the crash does not occur any more since I upgraded the driver for my Matrox G400 DualHead card. Thank you so much Chet for your patience. Confirming as fixed in build #19 of Hopper.
###@###.### 2002-09-03
|
Java
