[JOGL-250] Fix getChosenGLCapabilities for Java2D/JOGL bridge Created: 19/Nov/06  Updated: 19/Nov/06

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: kbr Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 250

 Description   

The new GLDrawable.getChosenGLCapabilities() does not provide correct answers
for the GLJPanel when the Java2D/JOGL bridge is active, and will provide a null
answer when called on an "external" GLDrawable. Should investigate whether it is
possible to provide better answers in these cases and to do so if possible.






[JOGL-243] Exception when destroying a Pbuffer while context is current Created: 14/Aug/06  Updated: 14/Aug/06

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: kcr Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File PbufferDestroyBug.form     Java Source File PbufferDestroyBug.java    
Issuezilla Id: 243

 Description   

If a Pbuffer is destroyed while a context created on that Pbuffer is current, an
exception will result the next time any context is made current. One could argue
that this is an app bug, but I am fairly certain that native OpenGL drivers
handle this case correctly.

To reproduce, run the attached test program. When you press the "DestroyPbuffer"
button, a new context is created on the Pbuffer, the new context is made
current, then the Pbuffer is destroyed. The following exception is thrown the
next time the on-screen context is made current:

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: Pbuffer
destroyed out from under application-created context
at
com.sun.opengl.impl.x11.X11PbufferGLContext.releaseImpl(X11PbufferGLContext.java:114)
at com.sun.opengl.impl.GLContextImpl.release(GLContextImpl.java:159)
at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:114)
at PbufferDestroyBug$MyCanvas.paint(PbufferDestroyBug.java:156)
at java.awt.Canvas.update(Canvas.java:114)
at sun.awt.RepaintArea.updateComponent(RepaintArea.java:239)
at sun.awt.X11.XRepaintArea.updateComponent(XRepaintArea.java:43)
at sun.awt.RepaintArea.paint(RepaintArea.java:216)
at sun.awt.X11.XComponentPeer.handleEvent(XComponentPeer.java:630)
at java.awt.Component.dispatchEventImpl(Component.java:4031)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

Note that if you check the "Release pcontext" check box prior to pressing the
"Destroy Pbuffer" button, then the app will release the context prior to
destroying the pbuffer and there will be no exception.



 Comments   
Comment by kcr [ 14/Aug/06 ]

Created an attachment (id=83)
Test program

Comment by kcr [ 14/Aug/06 ]

Created an attachment (id=84)
NB5 form file





[JOGL-164] Expose render-to-texture target Created: 05/Jun/05  Updated: 22/Jun/05

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Minor
Reporter: tedmunds Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 164

 Description   

The current render-to-texture functionality allows a Pbuffer to be bound to either
GL_TEXTURE_2D or GL_TEXTURE_RECTANGLE_NV (based on the value of
offscreenRenderToTextureRectangle set in the GLCapabalities object). However,
in some cases, the resulting texture target may not be what the programmer
expects (eg. if GL_TEXTURE_RECTANGLE_NV is not available). By adding an
accessor to GLPbuffer (and, hence to GLPbufferImpl as well as GLContext and all
its subclasses), the actual texture target being used could be made available to
the API programmer.

Issue 163 refers to an implementation that also includes an implementation of
this feature.



 Comments   
Comment by kbr [ 22/Jun/05 ]

Thanks for the suggestion and patch. However, the OpenGL community is moving
away from pbuffers and toward the frame buffer object extension, which is a more
portable and higher-performance solution for offscreen rendering than pbuffers.
I'm therefore reluctant to enhance JOGL's pbuffer implementation significantly
at this time, because we're trying to stabilize the final release of the current
JOGL APIs. Your patch will be considered for a future version of JOGL
implementing the JSR-231 APIs.





[JOGL-163] Extend Render-to-Texture functionality to include Render-to-Depth-Texture Created: 05/Jun/05  Updated: 07/Feb/06

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Task Priority: Minor
Reporter: tedmunds Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.cs.rutgers.edu/~tedmunds/jogl/renderToDepthTexture.zip


Attachments: Java Source File RenderToTextureFBO.java    
Issuezilla Id: 163

 Description   

The current render-to-texture functionality makes use of the
WGL_ARB_render_texture extension to allow a Pbuffer's colour buffer to be bound
to a texture. It would also be useful to be able to use the
WGL_NV_render_depth_texture extension to allow binding of the Pbuffer's depth
buffer to a depth texture. The implementation of such a feature (on Windows)
could parallel the already present render-to-texture functionality. An example
of such an implementation is available at
http://www.cs.rutgers.edu/~tedmunds/jogl/renderToDepthTexture.zip.

The implementation makes the following modifications to the JOGL code base:
net.java.games.jogl.GLCapabilities:

  • Add a boolean field offscreenRenderToDepthTexture (similar to
    offscreenRenderToTexture) that indicates whether the created Pbuffer should
    allow render-to-depth-texture.
  • Add accessors (getOffscreenRenderToDepthTexture(),
    setOffscreenRenderToDepthTexture(boolean onOrOff) for the above field.
    net.java.games.jogl.GLPbuffer:
  • Add a method bindDepthTexture() (similar to bindTexture()) that calls for
    the Pbuffer's depth buffer to be bound to GL_TEXTURE_2D or
    GL_TEXTURE_RECTANGLE_NV.
  • Add a method releaseDepthTexture() that parallel's depthTexture().
    net.java.games.jogl.impl.GLPbufferImpl:
  • Implement the added GLPbuffer interface methods (above) by calling the
    corresponding methods on the context (below)
    net.java.games.jogl.impl.GLContext:
  • Add an abstract method bindPbufferToDepthTexture() (similar to
    bindPbufferToTexture()).
  • Add an abstract method releasePbufferFromDepthTexture() (similar to
    releasePbufferFromTexture()).
    net.java.games.jogl.impl.windows.OffscreenGLContext/OnscreenGLContext:
  • Implement the added GLContext abstract methods (above) with versions that
    throw exceptions indicating that they should not be called.
    net.java.games.jogl.impl.windows.WindowsPbufferGLContext:
  • Add a field rtdt (similar to rtt) indicating whether render-to-depth-texture
    is enabled.
  • Add a field hasRTDT (similar to RTDT) indicating whether the
    render-to-depth-texture extension is available.
  • Add a field depthTexture (similar to texture) that holds the texture object
    ID of the depth texture.
  • Modify the constructor's DEBUG output to include rtdt.
  • Implement bindPbufferToDepthTexture() in a manner similar to
    bindPbufferToTexture(), except that the wglBindTexImageARB() call binds to
    WGL_DEPTH_COMPONENT_NV instead of WGL_FRONT_LEFT_ARB.
  • Implement releasePbufferFromDepthTexture() (with the same relationship to
    releasePbufferFromTexture()).
  • Modify createPbuffer(long, long):
  • Initialize rtdt from the capabilities.
  • On many of the tests that check whether rtt == true, modify to check
    whether (rtt || rtdt) == true.
  • If rtdt, add to the iattributes array the pair:
    WGL_BIND_TO_TEXTURE_RECTANGLE_DEPTH_NV or
    WGL_BIND_TO_TEXTURE_DEPTH_NV (depending on rect) and GL_TRUE (to enable
    binding of the depth buffer to a texture).
  • In the NVidia work-around loop, if rtdt, add the
    WGL_DEPTH_TEXTURE_FORMAT_NV and WGL_TEXTURE_DEPTH_COMPONENT_NV pair to the
    iattributes array.
  • Modify makeCurrent(Runnable):
  • Initialize rtdt from the capabilities.
  • Determine the render-to-texture-rectangle settings if rtt or rtdt is true.
  • If rtdt:
  • Determine whether the render-to-depth-texture extension is available.
  • Generate a texture to be bound to the depth buffer.
  • Bind the generated texture to the texture target.
  • Configure the texture lookup parameters.
  • Choose the internal format of the texture (one of the depth formats)
  • Create the texture with null contents.
  • Modify swapBuffers():
  • If render-to-depth-texture is enabled (rtdt), but the extension is not
    available (!hasRTDT), copy the depth buffer to the depth texture.
  • In both the new copying case and the existing colour buffer copy, bind the
    appropriate texture to the texture target before copying.
    net.java.games.jogl.impl.macosx.MacOSX*GLContext:
    net.java.games.jogl.impl.x11.X11*GLContext:
  • Not yet implemented (methods added with comments/exceptions to that effect)

Design decisions:

  • By paralleling render-to-depth-texture alongside render-to-texture, it is
    possible to bind both the colour buffer and the depth buffer of a Pbuffer to
    (different) textures.
  • For simplicity, the existing render-to-texture-rect settings are made to
    apply to both the colour and depth textures. It should be possible to allow
    (eg.) the colour buffer to be bound to GL_TEXTURE_RECTANGLE_NV, and the
    depth buffer to be bound to GL_TEXTURE_2D, but it doesn't seem that useful.

Notes:

  • The example patch was created against the latest source from CVS as of
    June 4, 2005.
  • As well as implementing the described render-to-depth-texture functionality,
    the example patch implements the exposure of the texture target (i.e.
    allowing the API programmer to determine whether the buffers are bound to
    GL_TEXTURE_2D or GL_TEXTURE_RECTANGLE_NV.
  • Also included in the source archive is and example application
    (RenderToTexture.java) that demonstrates the combined use of
    render-to-texture and render-to-depth-texture.


 Comments   
Comment by kbr [ 22/Jun/05 ]

Thanks for the suggestion and patch. However, the OpenGL community is moving
away from pbuffers and toward the frame buffer object extension, which is a more
portable and higher-performance solution for offscreen rendering than pbuffers.
I'm therefore reluctant to enhance JOGL's pbuffer implementation significantly
at this time, because we're trying to stabilize the final release of the current
JOGL APIs. Your patch will be considered for a future version of JOGL
implementing the JSR-231 APIs.

Comment by tedmunds [ 07/Feb/06 ]

Created an attachment (id=70)
Framebuffer object implementation of the desired functionality.





Generated at Fri Aug 26 18:40:10 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.