Bug 233

Summary: Shader settings destroyed when GLJPanel is garbage collected
Product: [JogAmp] Jogl Reporter: Sven Gothel <sgothel>
Component: coreAssignee: Sven Gothel <sgothel>
Status: VERIFIED WORKSFORME    
Severity: normal    
Priority: P3    
Version: 1   
Hardware: All   
OS: all   
Type: DEFECT SCM Refs:
Workaround: ---

Description Sven Gothel 2010-03-24 07:49:11 CET


---- Reported by kitfox 2006-07-05 05:23:38 ----

I've created a MDI program in which I can open multiple windows that contain
GLJPanels.  Within this window, I render an OpenGL teapot.  I've created a very
simple shader program with two simple shader objects attached to it.  (the
vertex shader just sets the position to the default, and the fragment shader
simply sets the fragment color to red).  I can compile and link them, and use
them to shade the OpenGL teapot.  When I create a second GLJPanel window in my
MDI and draw the same teapot in the second window, the teapots in both windows
appear correctly shaded.

Unfortunately, if I close both windows so that there is no GLJPanel visible, and
then create a new MDI window containing a GLJPanel, my teapot is no longer
rendered using the shader.  Its material and texture properties display
correctly, but the shader has no effect.  Recompiling and relinking the shader
here at runtime does not fix the problem.  

Worse, if I attempt to create a new shader to use, the new shader objects are
allocated names that match the names of the existing shader objects.  When I
compile the new shader objects, I get error messages about function "main"
already being defined.  Querying the old shaders via
glGetObjectParameterfvARB(..., GL_OBJECT_DELETE_STATUS_ARB, ...) does not
indicate the old shaders have been deleted.

Somehow my shaders are being deallocated when all GLJPanels are finalized, but
this is not remembered when I create a new GLJPanel.  

It might be possible that shader names are specific to a particular GLJPanel
instance, but this does not match the behaviour of either texture or pbuffer
names, nor does it explain the exception about function "main" already being
defined.

Is there a workaround for this?



---- Additional Comments From kitfox 2006-07-05 06:46:36 ----

Well, I can't seem to write a reproducable test case.  It looks more complicated
than what I originally surmized.  In my test case, I've created, destroyed, and
then recreated GLJPanels and the shader doesn't vanish.  However, I wish I knew
what was goinng wrong in my program.



---- Additional Comments From kitfox 2006-07-05 09:33:37 ----

Well, I can't seem to write a reproducable test case.  It looks more complicated
than what I originally surmized.  In my test case, I've created, destroyed, and
then recreated GLJPanels and the shader doesn't vanish.  However, I wish I knew
what was goinng wrong in my program.



---- Additional Comments From kitfox 2006-07-05 09:34:44 ----

I'm still not sure what's going wrong, but I've changed my code so that every
instance of a GLJPanel creates its own shaders, and that seems to work around
the problem.



---- Additional Comments From kbr 2006-07-07 14:18:54 ----

Since this appears to be an application problem closing as not reproducible.
Please reopen the bug if a concrete test case indicating a problem in the JOGL
implementation can be produced. You may find it useful to try to set up a
pbuffer which shares textures, display lists, etc. with all created GLJPanels;
note you will need to call display() on this GLPbuffer once to get its OpenGL
context created.




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

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