Re: [android-developers] Re: Honeycomb / 3.0 / OpenGL ES / Broken / Again!?!
On Wed, Apr 27, 2011 at 11:37 AM, MichaelEGR foun...@egrsoftware.com wrote: 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! I suggest that you calm down, ease up on the childlike ALL CAPS AND EXCLAMATION POINTS!!!, get rid of the profanity, and simply state that you believe that there has been a regression. 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!) Then, most likely, it would have taken you less time and less typing to write a test case that demonstrates the regression, then provided a link to it as part of your post. 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! Bugs happen. Cursing, shouting, and insulting developers will neither make the bug go away nor improve the quality of future code. Moreover, claims of bugs without reproducible test cases are next to useless, as any professional developer should realize. Should I file a bug? Yes. I cannot tell if there already is a bug report for this on b.android.com, because duplicate appears in quite a few issues, courtesy of issues being flagged as duplicate. However, there doesn't seem to be any hits on both duplicate and nio, so I am guessing that it is not there. That being said, don't bother if you're not going to provide a reproducible test case. I've already spent too much time tracking down the problem to create a separate test case. If quality was your top priority, you would not have wasted your time on the rant. Instead, you would have written the test case and therefore provided the evidence in a fashion that could be reproduced by other engineers. This might lead to a solution, either in the form of a fix to Android (if there is a bug) or a fix to your code (if what you were doing is outside the NIO contract but just happened to work). -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9.3 Available! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Honeycomb / 3.0 / OpenGL ES / Broken / Again!?!
On 27/04/2011 17:37, MichaelEGR wrote: 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. So many words and you still didn't actually say what ByteBuffer#duplicate is doing wrong in the first place. It's such a basic method that the test case is probably shorter than the rant ;) Would you care to share what the incorrect behavior actually is so other people can avoid this problem? Pepijn -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Honeycomb / 3.0 / OpenGL ES / Broken / Again!?!
Please file a bug at b.android.com and include a concise and accurate description of what is going wrong with duplicate(). Please also include, if possible, a reproducible test case so we can make sure the bug, if bug there is, is fixed on our end. Thanks. On Wed, Apr 27, 2011 at 9:36 AM, Pepijn Van Eeckhoudt pep...@vaneeckhoudt.net wrote: On 27/04/2011 17:37, MichaelEGR wrote: 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. So many words and you still didn't actually say what ByteBuffer#duplicate is doing wrong in the first place. It's such a basic method that the test case is probably shorter than the rant ;) Would you care to share what the incorrect behavior actually is so other people can avoid this problem? Pepijn -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Honeycomb / 3.0 / OpenGL ES / Broken / Again!?!
On 26/04/2011 07:54, Romain Guy wrote: What is the G-Slate you keep referring to?? LG's honeycomb tablet http://www.lg.com/us/mobile-phones/tablets/LG-V909.jsp I guess. Pepijn -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Honeycomb / 3.0 / OpenGL ES / Broken / Again!?!
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. On Mon, Apr 25, 2011 at 11:35 PM, MichaelEGR foun...@egrsoftware.comwrote: http://mobile-broadband.t-mobile.com/android-tablet/g-slate I believe it was previously called the LG Optimus Pad before release? It could be an issue from LG perhaps with a pseudo-incomplete GL driver and not in the court of the Android team / Google. One would think the default Honeycomb implementation I assume from Google was heavily tested against the Tegra 2 SoC and may exhibit the problem say on the Xoom or other Honeycomb tablet. I have yet to test anything beside the G-Slate. My assumption is that without being able to test directly (IE print out all the config profiles the GL driver returns to verify) is that the likely optimum depth size could be 32 for the Tegra 2 devices and that the max my config chooser currently searches for is 24 (2nd gen devices) and this is not present on Tegra 2 devices (3rd gen). Therefore depth 24 does not match anything and the further default fall back searches for depth size 16 which is located as a valid GL config found by TyphonRT. So 5/6/5/16 works OK with the G2x, but fails with the G-Slate. No EGL / GL errors are raised and 5/6/5/16 comes back as a valid config arrangement on the G-Slate, but it's broken such that no rendering occurs with this non-optimum config setting. The expected behavior I believe is that some sort of rendering should occur if a valid GL config is matched and a context obtained even if it is not the optimum config. Of note though there are no perceived performance problems with the G2x at this config setting. It seems obvious that 5/6/5/16 is not the optimum configuration for a Tegra 2 device (was the optimum setting for gen 1 devices). Once I modify the default fall back settings and include 5/6/5/32 as the top config to search after verifying that indeed is a valid target in general I'm guessing things will match up with the optimum supported config on Tegra 2 devices and things will be fine. It just happens that things are not borked on the G2x at 5/6/5/16, but the G-Slate fails with this setting further misleading me. As things go I've yet to add external settings (extra XML file / external config by exception, etc.) to configure GL config parameters, so until I finish rebuilding my platform in ~1-2 weeks I won't get to update the defaults or finish the external XML config mechanism. In the future with my efforts an external XML file that can filter by device / family as necessary can provide the GL config decision tree and not rely on the hard coded default decision tree, so testing will be easy in the future without recompiling. Regards, --Mike On Apr 25, 10:54 pm, Romain Guy romain...@android.com wrote: What is the G-Slate you keep referring to?? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Honeycomb / 3.0 / OpenGL ES / Broken / Again!?!
What is the G-Slate you keep referring to?? On Mon, Apr 25, 2011 at 8:09 PM, MichaelEGR foun...@egrsoftware.com wrote: Romain thanks for asking all the right questions. It appears that the GL config matching system I have needs a little modification though it should still not fail as I'll describe below. Of interest all 2nd gen devices (Droid, N1, Nexus S, etc.) appropriately find the high quality parameters as specified in the default fall back scheme (a config by exception system): EGL_RED_SIZE: 5 EGL_GREEN_SIZE: 6 EGL_BLUE_SIZE: 5 EGL_ALPHA_SIZE: 0 EGL_DEPTH_SIZE: 24 EGL_STENCIL_SIZE: 8 On the G2x / Froyo for whatever reason the high quality default settings are not matched and the mid quality default config is chosen, but everything runs perfectly fine and fast: EGL_RED_SIZE: 5 EGL_GREEN_SIZE: 6 EGL_BLUE_SIZE: 5 EGL_ALPHA_SIZE: 0 EGL_DEPTH_SIZE: 16 EGL_STENCIL_SIZE: 8 With the G-Slate the same mid quality config is chosen and a context and everything succeeds in being created with no EGL/GL errors except no rendering / blank screen. Even the 1st thing done in the demo is to set ortho mode and simply draw a texture to the screen (not rocket science here), so nothing complex is done regarding cameras or other typical GL problems and there are no hard coded parameters (screen size, etc.) that should break any fundamental rendering. There are also no other errors raised while the normal execution path / rendering loop engages. So for the G-Slate even though those config values result in a valid context currently it seems the GL drivers or something of that nature are not liking it despite this very same config working fine on the G2x / Tegra 2. As mentioned I've been doing a very large refactoring of the TyphonRT codebase making it a fully component oriented architecture and have been working on it since July 22nd (last day when I compiled all the demos). Granted I had a 5 month full time contract in between then and now working part time (Sept-Feb). I'm just about to finish the full component rearchitecture / refactor and get 3D support back up and running here in 1-2 weeks when I can address any changes to the GL config / chooser support. So the demo apps I've been using were last compiled back in July which is no problem really. I thought I had a robust enough of a default fall back system, but apparently not. I still think it may be a bug / issue with the G-Slate in regard to being able to setup a context with likely non-optimal settings causing a blank screen / no rendering. Something should still render regardless. A similar issue occurred with Android 2.0 and the Droid when the mid quality settings (essentially depth size of 16 instead of 24) caused a hang in the GL driver. 2.0.1 fixed that and when depth size 16 was chosen things worked, but less efficiently.. In my current case with the G-Slate those settings don't raise any errors or signs of failure except for no rendering which was the same symptoms surrounding the Android 2.0 failures and that got my mind running. Once I get the platform fully reworked here I'll examine things deeper and figure out the right default GL config fall back mechanism to support the G-Slate. I've been fairly stressed as of late with the remaining work I've been doing as it's complex and I'm overshooting desired time estimates. The last thing I need are fundamental driver issues. I admit I had 6 devices working with only the G-Slate failing and I tossed it in a proverbial tub of water and it floated and thus this it's a witch post occurred. ;P I still think there is a general error regarding GL support with the G- Slate especially since the G2x / Tegra 2 works fine with the same parameters, but this is a solvable problem and not the end of the world. I think each dev working with low level stuff should get at least one pass for an it's a witch post.. ;P Regards, --Mike On Apr 23, 10:03 pm, Romain Guy romain...@android.com wrote: What exactly doesn't work in your application? We have tested many OpenGL applications and games from Market, found and fixed bugs. We also sometimes found issues that were in the apps themselves but nothing as dire as what you are describing (although I couldn't really parse what your problem is exactly.) What fails? Do you see a crash? Are things not behaving as expecting? Do you get EGL/GL errors? How exactly are you initializing your context? There are no special workarounds or behaviors in GLSurfaceView btw. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer
Re: [android-developers] Re: Honeycomb / 3.0 / OpenGL ES / Broken / Again!?!
What exactly doesn't work in your application? We have tested many OpenGL applications and games from Market, found and fixed bugs. We also sometimes found issues that were in the apps themselves but nothing as dire as what you are describing (although I couldn't really parse what your problem is exactly.) What fails? Do you see a crash? Are things not behaving as expecting? Do you get EGL/GL errors? How exactly are you initializing your context? There are no special workarounds or behaviors in GLSurfaceView btw. On Sat, Apr 23, 2011 at 8:16 PM, MichaelEGR foun...@egrsoftware.com wrote: Yes apologies and thanks for your quick reply. You provide great info and are timely which is appreciated.. I'd be glad to buy a round for the Android team... um how large is it again? Android graphics team? um the really cool graphics folks? at I/O ;) I should not be allowed to post on the Internets after a long work session and these days its 6/7 days a week marching to launch as it's on my dime.. Do take it for semi-serious plus the lolz though; I know you guys work hard and Android has come a long way and it's still just beginning. I think it's spectres from Android's past that are nipping at my heels in this case due to the similarity. I'm just a little knackered that I think I know exactly the area things are failing in (init as things go) and I can't immediately fix or test it nor can I afford at the moment to get a Xoom or 3rd Tegra 2 device; will try and track a non G-Slate down though. It's just odd things work great on 1.5-2.3 OS across numerous devices, but not G-Slate / 3.0. I will let you know what I find out soon. For one brief flash while rapidly trying to rotate the screen w/ Auriga3D / quake 3 class engine I saw a flash of textures that all looked correct; I haven't been able to repeat that though and as things go though the intro screen for now is just a flat quad texture, so it should show up as it's not rocket science. The simple 3D cube demo of course is not working too, so init problem is likely and as mentioned when I get this massive refactor done (I'm about to unleash a component oriented platform of 550+ components that form a cross- platform Java middleware SDK w/ lots of goodies + base engine + component entity system support) I'll be able to test thoroughly the 3D demos in 1-2 weeks. I've been refactoring for months thoroughly moving away from strict OOP. It was much more work than I thought to create a robust component oriented platform. As I mentioned it's more spectres of Android's past haunting me and scaring me to death that something like this will happen after I release and potentially charge devs for a quality middleware platform. Basic GL init should just work across the majority of devices or failures detected and displayed to the user.. Black screen.. Not digging that so much. I'll be putting in extra effort to detect errors during init and display user actionable errors + error reporting. I actually have that in there now, so also perplexes me why nothing would pop up. Can you perhaps mention a Java based game of significant complexity that doesn't use the API/SDK GLSurfaceView.. I like to compare my efforts against Deadly Chambers, but it is using the API GLSurfaceView and works out of the box on tablets (G-Slate at least) with no / minor changes; nicely too on Tegra 2 devices. It would be good to reference other Java GL non API / GLSurfaceView oriented apps in times of crisis. Some general worries though.. I've not shipped yet, but soon and these issues again give me the jitters as I'd like to think other devs / users would understand, but not everyone is so forgiving especially when it's pro / paid middleware (GPLv3 w/ commercial license for the core). My hands are tied for now if you don't know of any specific underlying GL implementation method changes then I just have to get the demos back up and step through the init process and potentially test on another Honeycomb tablet. I'd offer sending you the simple 3D cube demo or anyone else for a head check and that would be much appreciated. Regards... On Apr 23, 7:03 pm, Dianne Hackborn hack...@android.com wrote: I am not aware of any existing GL applications that completely break like this. I have run lots and lots of the top applications on Xoom without trouble. Applications also haven't generally broken on previous platform releases, and I am pretty sure there are many applications on Market that don't use GLSurfaceView. To be honest, I don't have more time than to just scan through your long rant; it looks like most of what you are trying to do is let off steam than look for anything constructive, so I'll leave it at that. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send
