TextureIO.newTexture : No OpenGL context current on this thread

OpenGL Development JOGL Development
#1

Hi,

I’m having a small problem again.
I wrote a small texture cache for my textures, like


public class TextureCache {
    static Map<String, Texture> map = new HashMap<String, Texture>();

    public static Texture getTexture(String url) {
        Texture tex = map.get(url);
        if (tex == null)
            try {
                    tex = TextureIO.newTexture(new URL(url), false, TextureIO.PNG);
                   map.put(url, tex);
            } 
            catch (IOException e) {
                    e.printStackTrace();
            }
            catch (GLException e){
                e.printStackTrace();
            }
        return tex;
    }

Well this looks fine, but the problem is that it throws an javax.media.opengl.GLException: No OpenGL context current on this thread

Since there are about 10 different solutions available on the web, I would like to know, which one is the best, i.e. the most reliable and fastest way to get the current GL context. If anyhow possible, I would not like to use flags and stuff to call the function somewhere from my display-function.

Thank you very much in advance!

Oliver

#2

I suggest that you may have a look to the JOGL user’s guide: https://jogl.dev.java.net/nonav/source/browse/checkout/jogl/doc/userguide/index.html?rev=HEAD&content-type=text/html
Apparentely, it’s not possible to perform OpenGL calls from outside the OpenGL thread.

Maybe you can try to run your code inside the Threading.invokeOnOpenGLThread() method. But I’m not sure it will work.

To get the current context, you may call GLContext.getCurrent(). But if your thread is not the OpenGL one, I don’t think you may find any.

Jean-Baptiste

#3

Thank you for your reply.

After seaching around for a while, I have changed my TextureCache
into a TextureDataCache now, so on the background thread,
I load TextureData objects via TextureIO.newTextureData(…).
And in my display function (where the context is current),
I create Texture objects from those TextureData’s.
So this looks like:


if(textures[i] != null){
    textures[i].dispose();
    textures[i] =null;
}
long t1 = System.nanoTime();

textures[i] = TextureIO.newTexture(textureDatas[i]);

long t2 = System.nanoTime();
System.out.println(t2-t1);

The problem about this code is that it laggs like hell, also the time measurements confirm that:
I get output values in the order of, eg. 115572510, ie. eleven million nano seconds, that are 0,1 seconds!

How can I speed this up?

Thanks,
Oliver

#4

Appendix:

Also this alternative using updateSubImage does not lead to any improvements:


long t0 = System.nanoTime();

if(textures[i] != null)
    textures[i].updateSubImage(textureDatas[i], 0, 0, 0);
else
    textures[i] = TextureIO.newTexture(textureDatas[i]);

long t2 = System.nanoTime();
System.out.println(i+"  "+(t2-t0));

note that my TextureDataCache loads the TextureData objects via
texData = TextureIO.newTextureData(new URL(url), false, TextureIO.PNG);
so I am not using mipmaps.

I am absolutely sure, there must be a way to efficiently excange textures!

Please help,

thanks, Oliver

#5

How many textures are you loading?
How big are those textures?
Are you calling TextureIO.newTexture() each frame? because you don’t have to do that. The textures will persist between frames, then all you need to do is call bind() for each one you want to use.

#6

You could also try to disable mipmap generation. See http://www.java-gaming.org/forums/index.php?topic=18142.0

#7

:slight_smile:

Thanks!

In normal program operation it’s 3 Textures at a time.
No, I am not calling newTexture() each time, it’s just a call to texture.updateSubImage(TextureData) everytime.
Each of the textures has 24bpp at size 512x512.
And exactly this was the clue:
Before, I was using images of size 500x500, wich is not a power of 2. This small change
has brought me down to 1799391 ns = 1,8 ms per texturedata -> texture conversion.

But now: If you calculate that : 512 x 512 x 3 byte = 0,75 MB.
Ok, it takes 1,8 ms = 0,0018 s.
0,75 / 0,0018 = 416 MB/s.
Is this a good value?
I’m asking this question, since if this was all that was possible, then I would not have to search further.

best regards,
Oliver

#8

You might get better performance by using precompressed DXTn textures. The TextureIO can afaik handle compressed .dds files.

#9

I am still curious why you even have to update the texture data every time. Once you send it to the graphics card with the first updateSubImage() or newTexture() call, you don’t have to resend it unless your texture image is changing in some way.