ByteBuffers

[oNyx]

Ok. That OpenIL thread got me thinking (uh uh :P).

I thought about… garbage. Y’know with that awt stuff you load image data into an Image obj… pull the stuff out of it… put it into a ByteBuffer… upload it… and well then you have quite some junk floating around. A zombie ByteBuffer and a zombie Image, which need to be GCed.

Great.

With that tga thingy from JCD you create each time a new byte buffer. Ok no zombie Image there but a zombie ByteBuffer. Hm.

Ok. Then I remembered that ByteBuffer recycling thingy from the other thread.

So… what about creating a single ByteBuffer for your ImageLoader… each time you need a bigger one you create a bigger one (and nullify the other before)… and if it’s smaller you just set the limit (with limit()) accordingly.

I think it sounds great, because you won’t create s-loads of garbage at startup. But I’m not sure if other problems might arise (I’m no *Buffer expert).

So… any comments?

[princec]

Creating bytebuffers willy nilly kills performance. The only API I would be happy with is one in which I could load an image into a byte buffer that I had already provided, and if that buffer was too small, it would construct a big enough one and return that instead. Like:

ByteBuffer buf = ...
buf = ImageLoader.load(stream, buf);

That’s about as good as it can get I reckon. Mostly what happens next is simply that the buffer gets punted to OpenGL and forgotten about so there’s no need to keep 'em hanging around.

Cas

[oNyx]

Ah… ok. Yea, that sounds good. I think I’ll modify JCD’s like that… and I’ll also add a method without the buffer (in which case an internal [ImageLoader] buffer gets created if it doesnt already exist).