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
Bernd Kreimeier writes:
> OpenGL Red Book, p65-78, "Vertex Arrays"
> glColorPointer( GLint size, GLenum type, GLsizei stride,
> const GLvoid* pointer );
> used as
>glColorPointer( 4, GL_UNSIGNED_BYTE, 0, data );
>
> In Java, using byte[4] is simply way too expensive. The
> Col
Daniel W. Dulitz x108 writes:
> JNI performs endian conversion, if necessary, automatically.
> If you have a native method that wants a byte[], and it gloms together
> four contiguous elements and treats them as an integer according to
> the processor's hardware endianness, then your native i
Bernd Kreimeier writes:
> The only statement I found is in the VMspecs, basically
> saying:
>
> Multibyte data items are always stored in big-endian
> order, where the high bytes come first.
>
> Does this apply to "int" in memory? Is the VM on Linux
> using big endian and swaps when it int
