From bc7503c77892a9e14b10e8b8e9ce48b148c6fa4c Mon Sep 17 00:00:00 2001
From: Sven Gothel <sgothel@jausoft.com>
Date: Thu, 28 Jun 2012 21:32:48 +0200
Subject: SWT/AWT GLCanvas multithreading annotations (see commit
 1a91ec5c8b6fd9d9db7bc115569c369fe7b38e9b) ; AWT GLCanvas remove dead code.

---
 src/jogl/classes/com/jogamp/opengl/swt/GLCanvas.java | 13 +++++++++++++
 1 file changed, 13 insertions(+)

(limited to 'src/jogl/classes/com/jogamp')

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!
  * </p>
+ * <p>
+ * 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.
+ * </p>
+ * <p>
+ * 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())
+ * </p>
  */
 public class GLCanvas extends Canvas implements GLAutoDrawable {
 
-- 
cgit v1.2.3