From bc7503c77892a9e14b10e8b8e9ce48b148c6fa4c Mon Sep 17 00:00:00 2001 From: Sven Gothel Date: Thu, 28 Jun 2012 21:32:48 +0200 Subject: SWT/AWT GLCanvas multithreading annotations (see commit 1a91ec5c8b6fd9d9db7bc115569c369fe7b38e9b) ; AWT GLCanvas remove dead code. --- .../classes/com/jogamp/opengl/swt/GLCanvas.java | 13 ++++++++++++ .../classes/javax/media/opengl/awt/GLCanvas.java | 23 ++++++++++++++++------ 2 files changed, 30 insertions(+), 6 deletions(-) (limited to 'src/jogl') diff --git a/src/jogl/classes/com/jogamp/opengl/swt/GLCanvas.java b/src/jogl/classes/com/jogamp/opengl/swt/GLCanvas.java index 6fe9e33f6..7e1b69823 100644 --- a/src/jogl/classes/com/jogamp/opengl/swt/GLCanvas.java +++ b/src/jogl/classes/com/jogamp/opengl/swt/GLCanvas.java @@ -79,6 +79,19 @@ import com.jogamp.opengl.JoglVersion; * Simply locking before using drawable/context offthread * would allow a deadlock situation! *

+ *

+ * NOTE: [MT-0] Methods utilizing [volatile] drawable/context are not synchronized. + In case any of the methods are called outside of a locked state + extra care should be added. Maybe we shall expose locking facilities to the user. + However, since the user shall stick to the GLEventListener model while utilizing + GLAutoDrawable implementations, she is safe due to the implicit locked state. + *

+ *

+ * FIXME: [MT-2] Revise threading code + The logic whether to spawn off the GL task and + determination which thread to use is too complex and redundant. + (See isRenderThread(), runInGLThread() and runInDesignatedGLThread()) + *

*/ public class GLCanvas extends Canvas implements GLAutoDrawable { diff --git a/src/jogl/classes/javax/media/opengl/awt/GLCanvas.java b/src/jogl/classes/javax/media/opengl/awt/GLCanvas.java index 604dea057..bdfa11959 100644 --- a/src/jogl/classes/javax/media/opengl/awt/GLCanvas.java +++ b/src/jogl/classes/javax/media/opengl/awt/GLCanvas.java @@ -132,6 +132,20 @@ import jogamp.opengl.GLDrawableHelper; * + *

+ * FIXME: If this instance runs in multithreading mode, see {@link Threading#isSingleThreaded()} (default: single-thread), + * proper recursive locking is required for drawable/context @ destroy and display. + * Recreation etc could pull those instances while animating! + * Simply locking before using drawable/context offthread + * would allow a deadlock situation! + *

+ *

+ * NOTE: [MT-0] Methods utilizing [volatile] drawable/context are not synchronized. + In case any of the methods are called outside of a locked state + extra care should be added. Maybe we shall expose locking facilities to the user. + However, since the user shall stick to the GLEventListener model while utilizing + GLAutoDrawable implementations, she is safe due to the implicit locked state. + *

*/ @SuppressWarnings("serial") @@ -141,8 +155,8 @@ public class GLCanvas extends Canvas implements AWTGLAutoDrawable, WindowClosing private final GLDrawableHelper drawableHelper = new GLDrawableHelper(); private AWTGraphicsConfiguration awtConfig; - private volatile GLDrawable drawable; - private GLContextImpl context; + private volatile GLDrawable drawable; // volatile avoids locking all accessors. FIXME still need to sync destroy/display + private volatile GLContextImpl context; // volatile avoids locking all accessors. FIXME still need to sync destroy/display private boolean sendReshape = false; // copy of the cstr args, mainly for recreation @@ -388,10 +402,7 @@ public class GLCanvas extends Canvas implements AWTGLAutoDrawable, WindowClosing @Override public boolean isRealized() { - return ( null != drawable ) ? drawable.isRealized() : false; - } - protected final boolean isRealizedImpl() { - return ( null != drawable ) ? drawable.isRealized() : false; + return (null != drawable) ? drawable.isRealized() : false; } @Override -- cgit v1.2.3