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 <[email protected]> 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 [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
