Bug 63 - NoAutoRedraw paint behavior
Summary: NoAutoRedraw paint behavior
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 1
Hardware: All all
: P2 normal
Assignee: Sven Gothel
Depends on:
Reported: 2004-02-06 10:38 CET by Sven Gothel
Modified: 2015-09-27 03:14 CEST (History)
0 users

See Also:
SCM Refs:
Workaround: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2010-03-24 07:46:18 CET

---- Reported by andyskinner 2004-02-06 10:38:03 ----

My issue #62 is the result of trying to get a complicated multi-threaded approach 
to work with the assumption that the GLCanvas can only tell my app to do 
something through the GLEventListener interface.  I'd prefer a simpler approach 
that skips those issues altogether.

I'd really like only only thread (my rendering thread) to deal with Jogl.  However, I 
do want to be able to render when the GLCanvas gets a paint event.

This is my suggestion, though I'd be open to other ways of achieving the same 

In GLCanvas.paint(), add an else condition to the if that checks the autoredraw 
mode.  If autoredraws are turned off, call paint(g) on the GLCanvas's parent.

This allows me to set up GLCanvas, turn off autoredraw, and have my paint 
method tell my rendering thread when it can go.  Now I don't have to worry about 
thread synchronization issues trying to share Jogl between AWT calling display() 
and my rendering thread calling display(), and things are much cleaner.

I first thought of asking for another method on the GLEventListener interface, but I 
don't want the call to go through invokeGL(), which is synchronized.  Because I 
want to be in control of Jogl, I just want GLCanvas to let me know when it would 
have made a picture, so I could handle it in my own way (in addition to the way I 
initiate making a picture on my own).

If there is a good way to handle this already, I'd be interested in hearing about it.  
I'm trying to fit this into a large existing system, so I can't make too many 
architectural changes to my own stuff.


---- Additional Comments From kbr 2006-01-10 23:58:50 ----

The JSR-231 APIs have substantially revised the amount of control given to
applications as well as significantly changed how operations such as forcing all
GLAutoDrawable work on to a single thread are done. The NoAutoRedraw API has
been completely removed from the JSR-231 APIs as it is no longer necessary for
correctness. We believe the current JOGL implementation is significantly more
robust than earlier versions and request you try the current version if still

--- Bug imported by sgothel@jausoft.com 2010-03-24 07:46 EDT  ---

This bug was previously known as _bug_ 63 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=63