Bug 640

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.