I did finally isolate the issue after 3 days since I had to start from
a most fundamental level (thorough review from GL context creation on
up)... There seems to be a change to NIO buffers that is not playing
nice with the extended API I have built with them.. In particular it
appears the implementation of the "duplicate()" method is f'ed up in
HoneyComb!!!!
The extremely sad thing is that things work fine OS 1.0 - 2.3... So
what got borked with "duplicate()" in 3.0?
This makes me _EXTREMELY_ unhappy BTW as a large amount of code all
throughout TyphonRT relies on the extended NIO API in TyphonRT! Very
very very lucky that I was able to find a workaround, but Auriga3D is
borked still and there are many rendering artifacts and this bug
seriously impacts my work / product. I write near bullet proof code
and am pushing Java and Android rather far, so I am now calling "IT
REALLY IS A WITCH!"
----
The one trick that I do with my extended NIO buffer API is create a
"read / write head".... Here is the constructor of the base
NIOFloatBuffer found in TyphonRT... FYI NIOFloatBuffer is near the
root of the API and further up the chain is VectorBuffer3f that can
read/write vecmath data.
protected NIOFloatBuffer(int capacity, boolean direct, boolean
nativeOrder)
{
super(s_READ_WRITE);
if (capacity < 0)
throw new IllegalArgumentException();
if (direct && !nativeOrder)
buffer1 = ByteBuffer.allocateDirect(capacity *
s_SIZE_OF_FLOAT).asFloatBuffer();
else if (direct && nativeOrder)
buffer1 = ByteBuffer.allocateDirect(capacity *
s_SIZE_OF_FLOAT).order(ByteOrder.nativeOrder()).asFloatBuffer();
else
buffer1 = FloatBuffer.allocate(capacity);
read = buffer1.asReadOnlyBuffer();
write = buffer1.duplicate();
}
When a put is done it's done at the position of the write head and
reads occur from a different position in the buffer at the read
head...
The "workaround" is simply to not call duplicate() and simply assign:
"write = buffer1;"
In my NIOBuffer API now getBuffer() and getWriteBuffer() return the
same view of the underlying buffer. All my simple GL test apps popped
right back to life.. Auriga3D however has rendering errors that are
likely connected to this bug, but runs fine and stuff shows on the
screen unlike before with nothing. As things go I am using the July
'10 build of Auriga3D and substituting 2-3 jars from the modified July
'10 build before the massive component oriented architecture refactor
began, so for another 1-2 weeks until I finally finish the component
oriented refactory and bring up all the 3D support and rebuild
Auriga3D I won't be able to determine the full fall out of this
problem. Hopefully it's not catastrophic!
I can't tell you how disappointed I am with a further broken NIO
implementation or something screwy in Honeycomb / 3.0!!!! I am
positive the implementation of "duplicate()" is broken or changed as
it worked perfectly fine from 1.0 to 2.3 OS (recall I've been
developing over the whole range of OS releases with this code and
ported TyphonRT over from the desktop early on!)
While my rage is existential there is no doubt some serious
unhappiness here as every release of Android except 2.3 (as far as I
know) has major problems for low level developers. Do you guys even
unit test? (I know you guys do, but obviously not well enough!) This
should have been caught by unit tests! The TyphonRT NIOBuffer API has
worked perfectly fine on the desktop for years and all Android
versions 1.0 to 2.3!
Where do I send the 40 hour invoice at my corporate rate for this
one? Or I'll accept a Google I/O ticket which is much less.. ;P
Unfortunately my father was in the hospital/ICU when tickets were on
sale and I wasn't online then.. phew he made it out though!
SO ITS A WITCH! All my code including Auriga3D sprung to life (except
rendering errors with Auriga3D) once I removed the duplicate() method
usage in the TyphonRT NIO extension API. As things go this time a
catastrophic failure has _most likely_ been averted and there is
_probably_ a workaround for TyphonRT, but you know this still makes me
a little disappointed as now I have to have a borked or at least
modified interface / contract and there is likely fallout over this.
Seriously fix this s'ht and push out a 3.0.1 just like 2.0.1 and
forever get rid of this before 3.0 becomes more widespread!
Well.. Like I said.. I create near bullet proof code, so I knew when
things failed as spectacularly as it did that it likely was in
Google's court.
:: sigh ::
You guys gotta tighten up the ship... seriously; try not to mess up
more releases... It's embarrassing at this point and low level devs
are not pleased! If there was another reasonably popular mobile device
platform supporting Java I'd jump ship. I may sound irate, but I've
had to deal and work around an awful lot since Android 1.0. This bug
would have grounded my middleware / product and would have caused all
users / developers who have paid for my product to have their apps /
games fail hard. It's just simply not cool..
I will know the full extent of any fallout to this bug soon.
I do appreciate the responses from Dianne and Romain. I'm not angry at
either of you (existential rage and all), but I'd go for an I/O ticket
and all is forgiven.. ;P
Should I file a bug? I've already spent too much time tracking down
the problem to create a separate test case. I'm now not going to have
a private beta for I/O as it is due to this delay.
--Mike
On Apr 26, 9:19 am, Romain Guy <[email protected]> wrote:
> I have never seen or use a G-Slate, but I can tell you that Tegra 2's depth
> buffer is 16 bits. It cannot do 24 bits or more.
Yep.. I was trying to come up with a hypothesis as to why there might
be problems regarding the context attributes and reaching a bit there
until I got into the code again. I've yet to look in depth at the
Tegra 2 specifics.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
