Bug 78 - Re-assigning rendering thread causes subsequent display() to fail
Summary: Re-assigning rendering thread causes subsequent display() to fail
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 1
Hardware: All windows
: P2 normal
Assignee: Sven Gothel
: 80 (view as bug list)
Depends on:
Reported: 2004-04-26 10:31 CEST by Sven Gothel
Modified: 2010-03-24 07:46 CET (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:30 CET

---- Reported by yvg 2004-04-26 10:31:57 ----

Imagine I want to turn on FSAA on existing scene. I have GLCanvas created 
(canvasA), set up and running, and its rendering thread set to rendering thread 
of the app.

No the app wants to turn on FSAA. Inside the rendering thread, just after 
canvasA.display() it calls canvasA.setRenderingThread(null), then creates new 
canvasB with FSAA turned on, calls canvasB.setRenderingThread
(Thread.currentThread()), and then canvasB.display().

The code executing is similar to this:

GLCanvas canvasA = createCanvas(FSAA disabled);
GLCanvas canvasB = createCanvas(FSAA enabled);

In current implementation, canvasB.display() fails with "Surface already 
unlocked" exception.

The reason of this problem is that in GLContext.invokeGL() during the handling 
of canvasA.setRenderingThread(null) the second reference to canvasA's context 
pushed, and before freeing only one of the references popped from the stack. 
This causes that reference to context which is already freed left on the stack 
and during the next call to canvasB.display() GLContext.invokeGL() tries to 
free it again, which is invalid.

The simplest fix for this issue is to duplicate pop() operation for case when 
freeing context after setRenderingThread(null), i.e. replace fragment

if (mustFreeBecauseOfNoRenderingThread) {
  // Must match previous push()


if (mustFreeBecauseOfNoRenderingThread) {
  // Must match previous push()

in GLContext.invokeGL().

I tried this fix and it solved the problem.

Yuri Vl. Gushchin

---- Additional Comments From kbr 2004-04-30 15:06:48 ----

The code in GLContext.invokeGL() which keeps track of which GLDrawables are in
the process of rendering on the current thread was buggy, largely because it was
too complicated. A restructuring and simplification has made it easier to
understand and has fixed Issue 80, which is probably identical to this one.

Please retest with the nightly build dated April 31 and update this bug
indicating whether this problem has been addressed. This fix will be present in
JOGL 1.1 beta 04.

---- Additional Comments From kbr 2004-05-05 23:50:10 ----

Submitter confirmed that new code fixes this issue.

---- Additional Comments From kbr 2004-05-05 23:51:22 ----

*** Issue 80 has been marked as a duplicate of this issue. ***

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

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

Unknown bug field "has_duplicates" encountered while moving bug
     <when>2004-05-05 23:51:22</when>