Efficient Texture Updating

OpenGL Development JOGL Development
#1

I am currently writing an application that makes heavy use of Textures that are constantly being changed. More specifically, they are being updated from a BufferedImage. I was curious if there is a “best practice” in JOGL for updating Textures for performance and reliability?

I see that TextureData is useful as a separation to allow the data to be populated in a separate thread and then and then loading into a Texture in the GL thread but should one be created every time there is an update or should it be updated? I apologize for the newbie questions, and as far as OpenGL specifics go I’m reading quite lot but things that are specific to Java and/or JOGL I’m having a real hard time finding any good documentation for.

#2

As said, use glTexSubImage2D

Preferably, use the OpenGL parts of JOGL directly, not JOGL’s wrapper classes.

Because then, at least, you have absolute control over what happens. That’s actually very important when you’re debugging, because you don’t have to figure out how both OpenGL and the wrapper classes work. Both have their quirks.

Pure OpenGL is not that hard anyway - no need for an abstraction layer!

#3

So using Texture, TextureData, and TextureIO would not be preferable since they are specific to JOGL?

I’ll keep reading about glTexSubImage2D, thanks for being patient. :slight_smile:

#4

No, I said you should avoid them because they are an abstraction layer that just gets in your way when doing triavial stuff like pushing a few bytes to your GPU.

#5

You only have to have a quick browse of the forum to see how many people have issues with the Jogl-specific helper classes like TextureIO. Given the state-machine design of opengl, having opaque third party code tinkering with the state behind your back is a recipe for bugs and lots of tedious debugging.

I’m still at a loss as to why the utility stuff is included in the core jogl distribution - that kind of stuff should really be extracted out into a separate library because it just confuses newbies and is dead weight to everyone else.

#6

Alternatively, the documentation for the utility classes should be updated
to state clearly which GL states are affected and that users should be very
careful about restoring their states.

The complexity of the texture object often defeats a newbie, and most people
just end up writing their own wrapper. The utility classes have their use to
get newbies started quickly, but they need to know about the pitfalls and the
best way is put the warnings in the API reference.

.rex

#7

Or perhaps the utility classes should restore their state by default. People who consider that too much of a performance hit won’t be using them anyway.

#8

If supported PBO is the best way to ensure DMA xfer usage
plus you may benefit from an asynchronous transfer, if your use case allows it.

http://www.opengl.org/registry/specs/ARB/pixel_buffer_object.txt

It sounds odd, to map/unmap memory buffer,
even do a CPU/client side memcpy to the mapped buffer region,
but know that memcpy shall initiate a CPU/GPU DMA xfer as well.

I.e. last time I checked the ATI drivers were not utilizing DMA xfers
for plain TexSubImage2D … but using PBO allowed it.

Cheers, Sven