transfer images from TextureData to a Texture off of the EDT in JOGL

Hi,

I have to use very large 16MPix textures in my project. Unfortunately the whole application is freezing for about 1 sec. each time the TextureData is transfered to the GPU. I heard from the WorldWind Java team, that its not possible to do this in another thread asynchonously. Maybe you could add this feature?
Here the discussion about it:
http://forum.worldwindcentral.com/showthread.php?44261-Large-Surface-image-without-blocking-UI-Thread-on-loading&p=121544#post121544

Thx

-Marco

Hi

Most of the answer is in the Java documentation:

This is separated from the notion of a Texture to support things like streaming in of textures in a background thread without requiring an OpenGL context to be current on that thread.

http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/util/texture/TextureData.html

What tag wrote is partially wrong. I confirm that making an OpenGL texture requires to call glTexImage and glTexImage2D. I confirm that obviously these are OpenGL commands. However, executing OpenGL commands requires a current OpenGL context, this isn't specific to JOGL, it would be necessary even though you were using C or C++. JOGL is able to define the thread which accesses to the OpenGL context of the drawable as you can see in the documentation:
http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GLAutoDrawable.html#setExclusiveContextThread%28java.lang.Thread%29

You can write your own animator and return the thread you want:
http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GLAnimatorControl.html#getThread%28%29

However, as stated in the documentation, it can cause some troubles with AWT which isn't a limitation of JOGL but rather a limitation of AWT and as far as I know, there is NO other Java binding for the OpenGL API providing a very decent support of AWT and Swing, the only other API that comes to my mind is famous to provide a crappy AWT support for more than 10 years for historical reasons (because of some Sun employees who tried to "hide" some private APIs in JAWT).

Moreover, it isn't a good solution but it has nothing to do with JOGL. Making an OpenGL context current on different threads can work reliably with a good driver on some platforms but it isn't guaranteed to work everywhere.

Finally, the second paragraph of tag's comment contains several wise advises with which I agree.

Edit.: Transferring huge images to the GPU is slow and necessary to create textures from them. Splitting them into smaller ones is an option as "tag" suggested.

Hi,

thankyou for your hints.

I now compressing the data to DDS in another thread on the fly, which works really good for me. At least on my machine texture loading "freezes" are gone.

I allready realizes that I need to make thread the current context for GL. Even loading in another thread, I still got trouble since some other jogl parts running on the ui thread seesms to ask for a global lock, and finally waiting for this lock still causes UI freeze, even the work is done on another thread.

I knew that AWT needs to have everything in the event dispatch thread. but I don't know why just loading data inside jogl needs to set such a global lock which prevent me from doing real multi threading?

thx
-marco

You might have some troubles if you make the same OpenGL context current on several distinct threads and it has nothing to do with JOGL, it depends on multi-threading support in the driver. When it works, it is really fine :) You can be bothered by the AWT global lock if and only if you use an AWT drawable, typically the AWT GLCanvas. If you want to "do real multi-threading", use NewtCanvasAWT or GLWindow. Do you know whether WWJ provides a canvas based on NEWT? Do you absolutely need to use Swing and/or AWT in your application?

Edit.: WorldWindowGLCanvas uses AWT. It should be possible to write another WWJ canvas based on NewtCanvasAWT or preferably GLWindow.

Edit.2: AWTGLAutoDrawable is used in WorldWindowGLAutoDrawable. You'd need a drawable that doesn't make such assumptions on the drawables.

Edit.3: Actually, WorldWindowGLAutoDrawable should be divided into 2 classes, a "general" abstract drawable class with no dependency on AWT and a concrete class extending it that would do exactly the same thing than WorldWindowGLAutoDrawable but that would be in gov.nasa.worldwind.awt. After that, you could create a concrete drawable class using NEWT and extending the abstract drawable class. Finally, you could create a class WorldWindowGLWindow like WorldWindowGLCanvas but using NEWT instead of AWT.

On 08/01/2014 01:27 PM, Marco [via jogamp] wrote: Well, If you dare to look into our GLMediaPlayerImpl's StreamWorker thread,
you will see that we utilize a shared context running on a separate thread
which loads the texture from the movie decoder. Each finished texture frame
is then pushed to the full ringbuffer, ready to be used by the user,
which runs on a different thread, using the 'other shared GL context.'

I have elaborated on this here as well:
  <http://forum.jogamp.org/Best-way-to-prepare-an-Image-td4031731.html#a4031732>

~Sven