Some more clarification... The byte order is not preserved with
duplicate(), slice() and potentially other NIO methods, but those two
for sure.
So if you have a FloatBuffer w/ native byte order of LITTLE_ENDIAN
call duplicate() on it will result in a view with BIG_ENDIAN byte
order on Honeycomb.
You realize 0x1 is 65536 not 65535
On Apr 29, 8:14 am, MichaelEGR foun...@egrsoftware.com wrote:
Some more clarification... The byte order is not preserved with
duplicate(), slice() and potentially other NIO methods, but those two
for sure.
So if you have a FloatBuffer w/ native
Hah.. yes.. A minor oversight in prepping.. Doesn't change the bug
though..
Having spent over 45 hours to hunt and fix this issue in my NIO code I
don't really care to spend too much time on the write up / proof
reading. Back to actual productive work.. ;P
On Apr 28, 5:28 pm, Zsolt Vasvari
My fsm, Mike! You must either be sick or getting tired. A 2 paragraph,
140 words reply? SCNR, just kidding :) Glad to see you alive and
kicking. Thanks for the bug report, that will save me some grieve.
On 29 Apr., 02:49, MichaelEGR foun...@egrsoftware.com wrote:
Hah.. yes.. A minor oversight
4 matches
Mail list logo
