Resize offscreen drawable with GLDrawableHelper?

I work with JOGL exclusively through an offscreen drawable and BufferedImage.

When I need to resize the offscreen drawable, I call:

    drawable.getGL().getContext().makeCurrent();
    new GLDrawableHelper().reshape(drawable, 0, 0, aWidth, aHeight);

I mostly arrived at this through trial and error. It works, but occasionally the next drawable.display() throws and exception:

    com.jogamp.opengl.GLException: Caught IndexOutOfBoundsException:
        Required 1 remaining elements in buffer, only had 0 on thread AWT-EventQueue-0

So now I wrap my call to display in an exception handler. Any thoughts on what I'm doing wrong? Here are the source files:

    Create/resize Drawable: https://github.com/reportmill/SnapKitGL/blob/main/src/snapgl/DrawableUtils.java
    Drawable for BufferedImage: https://github.com/reportmill/SnapKitGL/blob/main/src/snapgl/RenderImage.java

Hello

Personally, I rather get the GLContext from the GLAutoDrawable instance by calling GLAutoDrawable.getContext() but it may change. Why not using an offscreen GLWindow instead?

I actually used to use a GLWindow, but that seemed slightly messier to create (had to move it offscreen). Plus I still resized the drawable (GLWindow) the same way with GLDrawableHelper (see the commented out code at the bottom of my DrawableUtils).

I will definitely use the drawable.getContext() shortcut though - I missed that one, thanks!

There's a project called ardor3d-screenshot that uses an offscreen GLWindow under the hood, I'm sure it doesn't need to use GLDrawableHelper.

Is it encouraged to avoid the generic "offscreen drawable"? To me it seemed simpler and cleaner to not have to worry about a window/panel/canvas. My ideal would be a "BufferedImageDrawable". My only real question is: what is considered the 'best practices' to resize an offscreen drawable?

Both have their pros and cons but an undecorated offscreen GLWindow could do the job. By the way, GLWindow doesn't need AWT and JOGL uses PNGJ to write PNG files. My only worry when I read your code is that you need to make the context current but you use a potentially invalidated context.

com.jogamp.opengl.FBObject is a good source of inspiration.

I prefer using GLDrawableFactory.createOffscreenAutoDrawable(..) for a resizable GLAutoDrawable and GLEventListener.

Otherwise, if I only need a manually hacked GLDrawable, use GLDrawableFactory.createOffscreenDrawable(..).

Both can be used for a shared GLContext.
For this, a shared GLContext, you may also use a dummy drawable
from GLDrawableFactory.createDummyDrawable().

Since I currently fix an EGL issue in this area and commenting here,
I see that we also could use the surfaceless drawable for GLDrawableFactory.createDummyDrawable()
if available - I will check on this, as it would reduce resources a bit further.

Unit tests for GLAutoDrawable showing its usage are available e.g. in
TestGLAutoDrawableFactoryES2OffscrnCapsNEWT
and GLMedialayerImpl uses GLDrawableFactory.createDummyDrawable().

I do prefer this low-level API, since a NEWT offscreen GLWindow adds more dependencies and resources
not required if you only want to have a non-windowing system offscreen (usually FBO).

GLDrawableFactory's createOffscreen[Auto]Drawable(..) uses the best implementation
if available, i.e. for FBO either createSurfacelessImpl(..) or createDummySurfaceImpl(..),
otherwise a generic createMutableSurfaceImpl(..) w/o FBO relation.

In the unit test class UITestCase, you will find a SnapshotGLEventListener,
which utilizes GLReadBufferUtil to take a snapshot from the current front framebuffer.
This essentially simply reads the pixels and writes a file using either format: png, netpbm, tga, ...

+++

The API doc system we still use, i.e. javadoc, is of poor quality,
as it does not properly link to the unit test examples automatically.
When I change this to Doxygen this shall be resolved.
Manual fix: Show call graph in the imported whole project in your favorite IDE.
Perhaps this also works well when loading the jar w/ sources.

 

Sven calls glad.display(), his unit test is smarter :)