Daniel Dulitz writes:
> I'm not sure why you think there's a redundant swap by JNI.
Well, I didn't, until I got into the VMSpecs and read a few
remarks. I didn't really expect the VM to use big endian
internally on little endian hosts, but then, I have seen
weirder things happening.
> Remember, the JVM spec says the JVM appears **from the perspective of
> the Java byte code** to be big-endian. There are very few Java byte
> code operations where endianness matters, so "in all likelihood"
Yep. No argument here.
> > >From Jack Middleton @ SUN, OpenGL ARB/interleaved array
> > > over JNI, stripped for this discussion:
> > > intVal = r;
> > > intVal = intVal << 8;
> > > intVal = intVal | g;
> > > intVal = intVal << 8;
> > > intVal = intVal | b;
> > > intVal = intVal << 8;
> > > intVal = intVal | a;
> >
> > Which breaks for the same reason, incidentally.
>
> The problem here, it seems to me, is that OpenGL is *not* using a
> packed integer, it is using an array of four bytes; yet the native
> interface is trying to use a packed integer.
Nope, that's Java. OpenGL does not consider this an integer,
and for those who do, it actually defines a GL_ABGR extension
to catch this situation. What happens is that I, Java side,
want to drop byte[4] in favor of int, and would like to
pass these values through to native code.
So did this Sun engineer. He event went further using
Float.intBitsToFloat to merge the RGBA value with float
x,y,z in a single array - which will obviously fail for
all but one NaN bit pattern.
> - Pass a byte array and hope you can lock it without copying,
> which you won't be able to do if the JVM has stored the byte
> array internally as an array of integers, or if the GC
> doesn't support locking. This is undoubtedly inefficient
> for small array sizes.
Yes. I set things up to have a single large array, but the
copying is an issue. I didn't think of a JVM that expands
byte to int in memory as well... not good. But then, on a
JVM that does not support pinning and copies, I might as
well bite the bullet and go down the call-intensive road.
> - Pass a fixed number of distinct byte arguments and let your
> native code arrange them. This is inefficient for large
> number of bytes,
Exactly. That's the JNI call intensive road, where the color
array is located in native code, and I do an equivalent of
a glColor(byte,byte,byte,byte) call.
> - Encode the bytes into integers as Sun suggests, but call a
> native method isBigEndian() to tell your Java method which
> field should be in the Java MSB so that things will come out
> right in the native representation. I've elaborated on this
> in a private email. In the general case this is probably
> the best option.
It might be a problem to keep final boolean BIG_ENDIAN proliferating
into all the color handling code, as I want to keep most color
data as packed int, and only use Color objects where needed.
> - Use a different interface to OpenGL, if there is one, that
> encodes r, g, b, and a as a real integer with r in the MSB,
> g in the next-MSB, b, in the next-LSB, and a in the LSB (or
> whatever). That eliminates the endian issue altogether,
Well, the API offers a lot of formats, but it doesn't really
consider byte[4] an integer - it's not needed in C. For pixel
formats, said GL_ABGR can do the trick, but for colors,
especially as arrays, it is GL_C4UB, which has a set order.
Interesting. I am tempted to say that chances are better the
ARB might address this, compared to the chance this can be
solved elegantly in Java.
> If JNI has a problem here, it's not that it guarantees that its values
> are in the endianness appropriate for the hardware, it's that passing
> byte arrays is too slow.
Right. Even more precisely - it's that byte[4] on the Java side
has too much overhead (is an object, has a length, does bounds
checking, the works).
> You are asking for something very strange, used only with the native
> interface, and even then used only when trying to pass *byte arrays*
> as integers.
True.
My conclusion is that the best place to pursue this is actually
with the OpenGL ARB (JavaGL bindings). It might be possible to
add some EXTensions or recommendations to OpenGL in order to
accomodate restrictions enforced by the Java language (not JNI,
actually).
b.
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
