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
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 interfaces native code?
Is a local int var
