my game is almost done, but it really really lags when uploading textures. :-(

OpenGL Development JOGL Development
#1

hello,

i am currently in the phase of finishing up my game for release, and the problem is (and it always was) that the rendering is pretty laggy when moving around. what happens when moving around, is that old textures are getting disposed and new ones are getting uploaded. these textures are sometimes quite large (512x512).

using the yourkit and the netbeans profiler i could track down that a majority of the time is spent in these two functions:

com.sun.opengl.util.texture.TextureIO.newTextureData(BufferedImage, boolean)
com.sun.opengl.util.texture.TextureIO.newTexture(TextureData)

my textures come from BufferedImages of types TYPE_4BYTE_ABGR or TYPE_CUSTOM, is that maybe the reason why the upload is so slow?
(TYPE_CUSTOM is because the BufferedImages are instantiated using BufferedImage(ComponentColorModel, Raster, false, HashTable)

maybe because the bufferedimage’s format is in a different byte order the opengl texture upload has to perform some reshufflng of the bytes in the texturedata?

thanks!

#2

It’s probably the texture object creation more than the fact that your BufferedImages are TYPE_CUSTOM that’s slowing things down. There are a few things you can try. First, keep a small pool of unused Texture objects of the appropriate width and height and use Texture.updateSubImage() with a new TextureData to change their contents. Second, you can try loading the TextureData objects in a background thread and handing them off to your main rendering thread for conversion to a Texture only when the contents are already in memory. Third, you can try converting your textures to a more efficiently handled format like DDS, which is handled natively by the TextureIO classes and hardware rather than going through a decompression step in ImageIO.

#3

thanks Ken,

  1. good idea, i will try that.

  2. i already do that. the problem is, that on older hardware with single-core cpus, this background thread is blocking the render thread, which causes even more lagging.

  3. i don think that imageio is the problem, because the textures are not read from disk. they are already in memory as javas2d shapes and areas and are rasterized on demand to bufferedimages.

#4

Have you already tried preloading all of the textures before doing this ‘moving around’ that’s slowing everything down? Because if you did that, then the only slow-down experienced should be between system RAM and your video card as the system bus between them shunts texture data back-and-forth (as opposed to spending time in some Java method that keeps making new textures).

#5

thanks.

that’s technically not possible in my game, since

  1. the area to move around is quite huge. there are a lot of different textures and all together wouldnt fit in vram.
  2. a big part of them are generated procedurally. some are rasterized from vector graphics. some have random text written into them.
#6

Conversion of TYPE_CUSTOM BufferedImages to OpenGL textures is more expensive than types which are supported natively by OpenGL. If you have control over the creation of the BufferedImage, use something like TYPE_INT_RGB or TYPE_INT_ARGB_PRE. See for example the demos.texture.TestSubImage demo in the jogl-demos workspace and compare the speed with which the “cursor” keeps up with your mouse pointer with the various image types. Most have a fast code path in to the TextureIO subsystem but a couple don’t; TYPE_BYTE_INDEXED is one example.

I think reusing the Texture objects and doing updateSubImage() calls is probably your best bet for a quick performance boost. I’ve also recently run into the huge expense associated with creating and destroying OpenGL texture objects.