Created attachment 384 [details] Log during jogl test run on kindle fire hd 7 Testing the jogl test apk on an Amazon Kindle Fire HD 7", results in: * lots of flickering * a crash after about 5 seconds Please find attached an extract of the log.
Created attachment 385 [details] NewtVersionActivity's log
Created attachment 386 [details] crash log with "nativewindow.debug", "jogl.debug" and "newt.debug" set to "all"
Created attachment 387 [details] crash log with "nativewindow.debug", "jogl.debug" and "newt.debug" set to "all" and "jogl.debug.DebugGL" set to "true"
Created attachment 388 [details] crash log with "nativewindow.debug", "jogl.debug" and "newt.debug" set to "all"
Created attachment 389 [details] crash log with "nativewindow.debug", "jogl.debug" and "newt.debug" set to "all" and traceGL = true
Created attachment 390 [details] crash log with "nativewindow.debug", "jogl.debug" and "newt.debug" set to "all" and traceGL = true and debugGL = true
The NDK's native demo san-angeles runs fine on the very same Kindle Fire HD device. That demo displays a 3D scene using native OpenGL code rather than using Android's Java API for OepnGL. This would mean the device's OpenGL driver is not at fault.
More testing shows : the problem occurs only with GLES1 The demo GearsES2 runs fine (i.e. neither flicker nor crash) (the crash I had with GearsES2 was due to missing shaders in the demo's paths) I'm updating the bug report's title.
You Attachment 390 [details] shows: Bind VBO and associate Vertex and Normal pointer, then unbind it. W/System.err(10451): glBindBuffer(<int> 0x8892, <int> 0x7) W/System.err(10451): glVertexPointer(<javax.media.opengl.GLArrayData> GLArrayDataWrapper[mgl_Vertex, index 32884, location -1, isVertexAttribute false, dataType 0x1406, bufferClazz class java.nio.FloatBuffer, elements 84, components 3, stride 24b 6c, buffer java.nio.FloatToByteBufferAdapter, status: capacity=252 position=0 limit=252, vboEnabled true, vboName 7, vboUsage 0x88e4, vboTarget 0x8892, vboOffset 0, alive true]) I/ActivityManager( 207): Start proc com.amazon.dcp:Settings for content provider com.amazon.dcp/.settings.SettingsProvider: pid=11060 uid=32028 gids={2001, 3003, 1015, 3002, 1007, 1026} W/System.err(10451): glNormalPointer(<javax.media.opengl.GLArrayData> GLArrayDataWrapper[mgl_Normal, index 32885, location -1, isVertexAttribute false, dataType 0x1406, bufferClazz class java.nio.FloatBuffer, elements 84, components 3, stride 24b 6c, buffer java.nio.FloatToByteBufferAdapter, status: capacity=252 position=0 limit=252, vboEnabled true, vboName 7, vboUsage 0x88e4, vboTarget 0x8892, vboOffset 12, alive true]) W/System.err(10451): glBindBuffer(<int> 0x8892, <int> 0x0) Now enable Vertex and Normal pointers: W/System.err(10451): glEnableClientState(<int> 0x8074) W/System.err(10451): glEnableClientState(<int> 0x8075) From here on .. something happened we don't see and the window is dead. W/InputDispatcher( 207): channel '4156c3f8 com.daysofwonder.android.testapp/com.daysofwonder.android.testapp.GearsActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x8 E/InputDispatcher( 207): channel '4156c3f8 com.daysofwonder.android.testapp/com.daysofwonder.android.testapp.GearsActivity (server)' ~ Channel is unrecoverably broken and will be disposed! I/WindowManager( 207): WIN DEATH: Window{4156c3f8 paused=false} I just assume that this is a 1:1 test of our GearsES1 activity demo, but since I read your GearsActivity here I guess not. Just for the purpose of validation, please produce this data w/ our original test case otherwise this statement may mean nothing here. Further more, I would like to see our original GearsES2 activity demo being tested, since it involves less layers (read: not the android surface flinger renderer). If all of this comes to the same conclusion, I would need to have such a device to get my hands on it, I am afraid.
Reduced severance to 'normal', since bug is reported for: [1] - Amazon's Kindle non std. software/driver setup [2] - GLES1 [3] - software renderer 'surface flinger' (Google's impl. probably using ES2) [4] - GLES2 works properly Due to [1] and no other occurrence of this crash, I may close this 'bug' as 'invalid' if no further discussion occurs here. ~Sven
See comment 10 - probably a bug within the ES1 software rendering or other areas .. ES2 works reliable.