Posted by Sven Gothel on Jan 23, 2013; 12:24am
URL: https://forum.jogamp.org/glDeleteBuffers-Very-Inconvenient-tp4027988p4027991.html

On 01/22/2013 11:51 PM, millerni456 [via jogamp] wrote:
> Hello All,
>
> I've run into an issue with Java OpenGL:
> The issue is that if I want to delete any buffers that I generated (such as
> for VBO's), and I am required to have a handle to an OpenGL context.
>
Of course. and not only a handle to 'an' (-> any) OpenGL context,
but the handle to _the_ OpenGL context used to creat this object,
or a shared one!

> But, in a game, if I constantly recreate these buffer,
Why would anybody would do that ?
As w/ any API - dynamically creating objects on the fly is always
a performance hog and should never ever happen!
Better reuse buffers, cache or pool them .. don't waste performance
on resource management while doing your animation, whether it's Java,
OpenGL or whatever.

> I will need to keep
> cleaning after myself (which unfortunately reveals the abstraction Java has).
> Also, I need to be able to delete these buffers on a non-OpenGL thread.
By definition, an OpenGL thread is a thread which has an OpenGL context current.
There is no _the_ OpenGL thread.

>
> I realize there are ways to get the OpenGL context on a thread that doesn't
> have one, but If I continually do this, wouldn't this create a major
> performance drop?
Depends on implementation of OpenGL (i.e. Mesa3D is fast in switching context),
but in general it's indeed better to not switch the GLContext all the time.
Hence we now have the Exclusive Context Thread (ECT) feature:
  <http://jogamp.org/git/?p=jogl.git;a=commit;h=224fab1b2c71464826594740022fdcbe278867dc>
>

> Anyways, I was really hoping there would be some way that Garbage Collection
> would delete these buffers, but that doesn't seem possible.

And it is not desired at all -> see my reply to your follow-up post.

Using and relying on GC (and/or temporary objects) in a high performance workflow
is just the wrong design.
A lesson to be learned from embedded, RT and security critical development,
where resources are scarce and no time shall be wasted by ioctl kernel calls
like memory allocation. Note: A Java NIO memory allocation is almost equal
to a kernel memory mapping within PAGESIZE -> costly!

Well, if you use the GLEventListener model, you can use dispose(..)
to release all your GLContext resources.

If you don't .. you need to add a hook to the GLAutoDrawable implementation
(override .. or whatever) to receive the 'about-to-be-destroyed' windowing system
message to issue proper cleanup while your GLContext is current.
The latter should be performed with a programmatic exit as well.
Again: All this is ensured if you use GLEventListener ..

Hope this helps.

~Sven