aboutsummaryrefslogtreecommitdiffstats
path: root/src/net/java/games/jogl/Animator.java
diff options
context:
space:
mode:
authorKenneth Russel <[email protected]>2004-06-19 01:58:40 +0000
committerKenneth Russel <[email protected]>2004-06-19 01:58:40 +0000
commit8f1783018b2df30d1ba59866cfde9f884da5ad97 (patch)
tree30a815946edbf281d927a7b607bff18f9a6294f9 /src/net/java/games/jogl/Animator.java
parent8fc1f6b579fa953abf7627df1198bf1677b9e54f (diff)
This putback attempts to address the following issues:
Issue 59: GLContext Leak Issue 67: Java/Jogl app hangs some systems, not others, during reshape. Issue 69: Error on window resize Issue 89: Losing Backbuffer when Resizing/Moving a window The primary change is to support handing off of the display() implementation to the AWT event queue thread via a new class called SingleThreadedWorkaround in the impl package. This was done to cause the AWT's reshape code to execute on the same thread as all other OpenGL rendering without changing the threading model (e.g., Animator and the ability to manually call display()) visible to the end user. This set of changes appears to work around the problems seen on ATI cards with random corruption when resizing animating windows due to multithreading bugs in the drivers. More testing by a larger community will confirm this fix. Currently the workaround is enabled by default on ATI cards. A secondary but related change is to properly destroy the OpenGL context when a heavyweight component is removed from its container. In order to implement the above workaround, it was necessary to override addNotify and removeNotify to properly track whether GLCanvases were realized; at that point it was a fairly small step to properly delete and recreate OpenGL contexts. The previous heuristics which attempted to determine when a heavyweight had been realized have been removed. A new demo, TestContextDestruction, exercises the new functionality. It does still appear to exhibit resource leaks, however; removing and re-adding the GLCanvas from its parent multiple times causes the system to eventually slow down significantly. More work is needed in this area. However, the demo does now execute as opposed to throwing an exception which was the previous behavior. The current code has been tested on Windows on NVidia hardware with all existing demos with the workaround both enabled and disabled, and on ATI hardware with the existing compatible demos with the workaround enabled. The new abstract method in GLContext, destroyImpl(), has been implemented but not yet tested on X11 and Mac OS X. git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@132 232f8b59-042b-4e1e-8c03-345bb8c30851
Diffstat (limited to 'src/net/java/games/jogl/Animator.java')
-rw-r--r--src/net/java/games/jogl/Animator.java18
1 files changed, 17 insertions, 1 deletions
diff --git a/src/net/java/games/jogl/Animator.java b/src/net/java/games/jogl/Animator.java
index 5ab2aad75..e844c1501 100644
--- a/src/net/java/games/jogl/Animator.java
+++ b/src/net/java/games/jogl/Animator.java
@@ -39,6 +39,9 @@
package net.java.games.jogl;
+import java.awt.EventQueue;
+import net.java.games.jogl.impl.SingleThreadedWorkaround;
+
/** <P> An Animator can be attached to a GLDrawable to drive its
display() method in a loop. For efficiency, it sets up the
rendering thread for the drawable to be its own internal thread,
@@ -113,7 +116,12 @@ public class Animator {
// during display(), so don't disable the rendering
// thread again.
if (noException) {
- drawable.setRenderingThread(null);
+ // Destruction of the underlying GLContext may have
+ // disabled the setRenderingThread optimization out
+ // from under us
+ if (drawable.getRenderingThread() != null) {
+ drawable.setRenderingThread(null);
+ }
}
} finally {
synchronized (Animator.this) {
@@ -133,6 +141,14 @@ public class Animator {
finished. */
public synchronized void stop() {
shouldStop = true;
+ // It's hard to tell whether the thread which calls stop() has
+ // dependencies on the Animator's internal thread. Currently we
+ // use a couple of heuristics to determine whether we should do
+ // the blocking wait().
+ if ((Thread.currentThread() == thread) ||
+ (SingleThreadedWorkaround.doWorkaround() && EventQueue.isDispatchThread())) {
+ return;
+ }
while (shouldStop && thread != null) {
try {
wait();