JNI passing data from Native to Java

Performance Tuning
#1

I need to pass texture data (bytes) from Native side to Java. What is the best way to do it, performance wise?

The only way I know would be to create an array of bytes and return it to Java. But that kinda seems slow to me.

EDIT-

I found this page while googling

Which is faster?
Create temp array of jbyte, do env->SetByteArrayRegion
Or just env->SetArrayObject(obj, int index) (Or something like that)

EDIT–

Is there any mechanism for printing error in JNI?

#2

The best way is to wrap the native data in a ByteBuffer using NewDirectByteBuffer and pass that to Java.

#3

[quote=“trollwarrior1,post:1,topic:51696”]
Allocating an array and doing a block copy of memory into it shouldn’t be a slow operation. Is the native code reading the textures in from a file? If so that’ll be taking much much, much longer.

Using the nio direct ByteBuffers as a matter of course isn’t ideal IMO. They may not even turn out to be faster in any given case according to the doc quoted above.

#4

I’m rendering some fonts using FreeType, converting rendered text to byte buffer and sending it to java to be used as textures.

#5

This is out of topic, but just now I realized that my Text Renderer has some huge mem leaks, so I tried to ‘make it bigger’ just to see what happens, and it so happened that Windows stopped responding completely. I got an error that said that I should restart my computer by pressing escape button (Which didn’t work) or manually if escape button didn’t work.

I’m surprised that I was able to mess Windows so much just by simply allocating memory.

#6

Off Topic: If you allocate so much memory that Windows doesn’t have enough to operate normally it will mess Windows up.

#7

The joys of C!

#8

I would just think that Windows would kill the application and clear it memory if something like this happens o-o

#9

you’re too used to a JVM!

#10

To be fair you kind of expect Windows to not allow programs to kill it. Windows is the equivalent of the JVM. It’s like the JVM crashing when a Java program doesn’t catch an exception. I suspect that Windows did not crash but rather it slowed down trying to find more memory to use and seemed to be non-responsive.

#11

Actually I don’t think Windows ever ran out of memory. It ran out of RAM… so it went into swap hell.