glGenTextures and Java

Hi,

I don’t suppose there’s a way to get around having to call

eglCreateWindowSurface

and

eglMakeCurrent

before making any calls to

glGenTextures

in the Java implementation of OpenGLES is there? The main problem is that at the time I come to create the textures (loading scene graph from file) I don’t yet have access to the Graphics object being used (it’s a cross platform API… long story) and so I need to create the glTextures, but at this point have no Graphics object to use with eglCreateWindowSurface, to then use with eglMakeCurrent. So I’m getting an IllegalStateException with “no current context”. Is it possible to create an “empty” context to make these calls with?
Basically I don’t understand exactly why the Graphics object needs to be known at this point, I’m a little fuzzy on the ties between these function calls and the context. Are all textures created with a certain context set current only usable when that context is set current?

Er… ta in advance. And if it sounds like I don’t know what the chuff I’m talking about that’s probably true.

Hi.

In general you need a current context before calling any opengl functions. If you haven’t initialized EGL before calling them bad things will happen.

Are all textures created with a certain context set current only usable when that context is set current?

Yes. Textures are always local to the current context. However - if you’re lucky and the OpenGL/ES implementation you’re using supports resource sharing you can share textures between different contexts as well. Take a look at eglCreateContext.

To your problem:

If the only function you want to call before creating the context is glGenTextures you can work around the problem. glGenTextures just returns you a free texture id to be used for glBindTexture. It’s a utility function.

You can manage the textures yourself if you want to. This can be as simple as an integer counter. All integers except null are valid texture id’s. No need to call glGenTextures.

Aha… good idea. I’ll give that a shot, thanks.

No go I’m afraid.

Here’s the thing… from the MIDP spec:

Operations on this graphics object after the paint() call returns are undefined. Thus, the application must not cache this Graphics object for later use or use by another thread. It must only be used within the scope of this method.

Implied from this is that the Graphics object could change with each call to paint() and that the only place that it is safe to use the object is within the bounds of the paint() method. If that is the case then surely, as a Graphics object is needed during the creation of an EGL context, the context will need to be recreated and set with each call to paint? Not only that but any texture setup will also need to be performed again if these textures are bound to the current context, which feasibly could not be the same as the last render frame.
Even if that is not the case, this still means that the only ‘safe’ place to initialise GLES is within the paint() method, and I really don’t want to have to do that.

What exactly are you trying to implement?

Well, so far I’ve written a Java 3D loader/scene graph manager under a common API that wraps M3G and Mascot and hides the details from the user. They can just load a file and render it on any platform without having to ever refer to M3G or Mascot directly.

Now I’ve come to add an OpenGLES implementation of the API and I’ve run into a problem with the timing of the scene graph loader.

Both previous versions can load the scene into memory without having to know anything about how it is going to be rendered later on. They both then have a renderStart/renderEnd method pair which takes a Java Graphics object as a parameter, and uses it for rendering, then releases it. This is the only time it currently needs the Graphics object.

Of course, now that GLES needs the Graphics object during the scene graph initialisation (to create a context that is then used by GL function calls), this all goes out of the window. I’ve managed to get the whole thing working by storing a list of textures that need creating, and creating them on the first call to renderStart(Graphics g_), which is the first time the Graphics object is actually known. However, I really don’t like this solution.

The API was designed so that any old Graphics object could be passed in to use as a render target to the renderStart/RenderEnd pair, and GLES doesn’t fit in with this. I’d have to recreate surfaces and recreate textures each time a new object was passed in. In fact, in the examples I’ve seen, the Graphics object is stored during Canvas creation and then used throughout the app, something which the MIDP spec says is unsafe to do.

So in essence, I’m desperately trying to find a way to create those textures at the application initialisation stage, independently of any Graphics objects that may or may not be used for rendering later on.

Are you implementing this in Java using JSR-239 or in native code?

Using JSR-239.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.