JOGL2 TextureIO missing newTextureData method???

OpenGL Development JOGL Development
#1

Hi, I’m looking to port over to JOGL2, but I can’t find these methods in JOGL2’s TextureIO:


public static TextureData newTextureData(BufferedImage image, boolean mipmap)

and


public static TextureData newTextureData(BufferedImage image, int internalFormat, int pixelFormat, boolean mipmap)

Also, the constructor for TextureData taking a BufferedImage is missing:


public TextureData(int internalFormat, int pixelFormat, boolean mipmap, BufferedImage image)

Is there a reason why they aren’t there any more? They were very useful!!!

-spiraljetty

#2

Ok, it looks like they were moved to the subclass AWTTextureIO.

#3

i got the same problem with the missing texuredata.

what did you use/import to get it to work?

import java.awt.textureio ?!?

greetings

#4

com.sun.opengl.util.texture.awt.AWTTextureIO

Please read the documentation:
http://download.java.net/media/jogl/jogl-2.x-docs/

#5

much thx @gouessej

it works

#6

Yes, but there is still the issue where calling newTextureData fails if the openGL context is not active. newTextureData basically now exactly the same as newTexture, which means the the TextureIO functionality is broken-- you have to set up your own threads to manage loading data, etc.

-sj

#7

No, create the texture in the display (or init) method of the GLEventListener, it is not broken, it works. If you create another thread to do such operations, you will have to make the OpenGL context current, it is not a better solution on my view. It is not a problem, obviously the creation of a texture requires a current OpenGL context.

Edit.: sorry to say this once more but that is already what I do in TUER. An OpenGL progress bar is displayed while the textures are created in the display(GLAutoDrawable glad) method.

#8

No, you are misreading me. I don’t want to create another thread to load in textures. And I don’t always want or to am not able to load them in the init method-- I may not know what they are initially for example, or the are chosen dynamically by the user somehow. Creating them in the display method stalls the animation. The previous version of TextureData worked perfectly to address this situation. The idea of textureData is that the expensive operation of loading in the data from disk or via a URL is done outside the openGL loop. Then the fast process of turning that data into a texture is done on the display loop. And of course any updates to that texture are super fast using updateImage or updateSubImage. Right now the original TextureIO.newTextureData (or AWTTextureIO.newTextureData) is broken. It functions exactly the same as regular newTexture. That is, it unnecessarily requires the openGL context to be active.

Cheers, sj

#9

the bug is already known:
https://kenai.com/bugzilla/show_bug.cgi?id=975
https://kenai.com/bugzilla/show_bug.cgi?id=998

#10

I know-- I filed the second of those bugs. And I filed a duplicate of the first of them on the old jogl issue tracker. I guess I keep bringing this up because I haven’t heard any feedback about them via the issue tracker or this board. I’d also be happy to invest some time in fixing them myself-- for example a fix for the second bug might be as simple as commenting out a single (undeeded?) reference to GL2. But since I don’t have a sense of the reason for the changes in the first place or a vision of what a finished version of jogl2 is supposed to be I’m not sure where to start. For example, is awt being deprecated in place of newt? And should things like TextureRenderer and TextRenderer even be a part of JOGL2? If they are, why not add in some other utility classes? Also, is there a whole community of people fixing bugs and making changes? Or it is just a single super busy person? It looks like there has only been 5 bug reports in the last few months. Of course, I could just clone the project and fix the bugs I am concerned about. But since I use things like bienator’s netbeans pack all the time I’d like the changes to be propagated to other projects. Speaking of which, it seems like the only updates are via the nightly builds, and that the only indication of changes is via the commits mailing list-- that is, there is no high level roadmap of what is going on with the project (as far as I can tell). Ok- I promise never to bring up the TextureIO bugs here again!

-sj

#11

jogl has at least one payed maintainer at sun (http://blog.jausoft.com/) who works as far as i know on plugin3 (i guess java6u18) as well. JOGL will keep supporting AWT (while adding NEWT and SWT to the list). NEWT is kind of a minimal implementation, it won’t (can’t) replace AWT.

the master plan is to release JOGL2 as reference implementation for the maintenance release of JSR231. I am currently working on http://kenai.com/projects/jocl thats why i am from time to time involved in the build (gluegen etc) of jogl.

[quote=“spiraljetty,post:10,topic:34133”]
If you find a way fixing it… i am sure your patch will be welcome. The worst thing what could happen is that you have a working solution for your problem until the bug is fixed in a other way (api change or something like that). As soon there is a new beta build available i will also update the version which is bundled in the NetBeans Pack.

#12

Im hearing a lot of plugin3 where can i find more info about it?

#13

Ok sorry, I see what you meant. However, I manually separate the costly process of loading the data and the creation of the OpenGL textures, I split the whole loading into several rounds in order to avoid freezing anything even on a single core machine. Now I understand that newTextureData did this separation, that’s the broken thing.