My understanding is that using a single GL context simultaneously on multiple threads gives undefined results.
By undefined I mean that the underlying graphics driver is allowed to: * do what you expect * fail and return an error * fail silently * make some toast :) ie. anything else. With Android running on so many different chipsets (and therefore different manufacture's OpenGL ES drivers) I think you should expect your code to fail in interesting ways on some devices. On Sunday, July 1, 2012 3:04:54 PM UTC+1, [email protected] wrote: > > Below is my curet uploading and use of the texture from the renderer's > onDrawFrame(GL10 go) method. I would simply like to call > gl.glCompressedTexImage2D from another thread, oftentimes many milliseconds > before the rendering thread is ready to be called. I place the rendering > code within a try lock block and on other platform, I place the upload > request within a lock block. If the renderer comes along why another > thread is uploading the texture, it request that the context be rendered > again and returns from the request without doing anything. When the > renderer successfully enters the try lock block, then outside threads are > blocked from updating the texture until the rendering thread completes it's > work and releases the lock. This is very basic and works on smoothly on 4 > other platforms, but my research so far has led me to a universal answer of > "you can't do this". I imagine that I could if I wanted to kick the > rendering in the realm of the NDK, but I thought I'd ask for an > authoritative answer first ... > > m_textureBuffer.rewind(); > > gl.glCompressedTexImage2D( GL10.GL_TEXTURE_2D, > > 0, > > GL10.GL_PALETTE8_RGBA8_OES, > > m_textureWidth, > > m_textureHeight, > > 0, > > m_textureSize, > > m_textureBuffer); > > > gl.glColor4f( m_textureColor, > > m_textureColor, > > m_textureColor, > > 1); > > > gl.glDrawArrays(GL10.GL_TRIANGLE_STRIP, 0, 4); > > > On Sunday, July 1, 2012 12:26:01 AM UTC-7, Romain Guy (Google) wrote: >> >> Hi, >> >> How exactly are you uploading the texture on that other platform? Are you >> simply doing an eglMakeCurrent() to reassign the GL context to another >> thread or are you using an EGLImage? >> >> On Saturday, June 30, 2012 4:33:32 PM UTC-7, >> [email protected] wrote: >>> >>> Hello, >>> >>> I am optimizing an OpenGL-based application ported from that other >>> major mobile OS and find that I cannot successfully access the GL >>> context from anything other than the rendering thread of >>> GLSurfaceView. What I CAN do on other platforms is upload my single >>> (and large) texture to GL prior to needing to render the texture >>> itself. This is a 640x480 8-bit RGB texture that takes some time to >>> upload to the chip and needs to be done every time I realize a new >>> frame of animation from the background system memory buffer. I'm sure >>> you can appreciate the savings in execution time if I can perform this >>> upload from another thread when I have nothing left to do but wait for >>> GLSurfaceView's rendering thread to call me. All is synchronized >>> safely as evidenced by the successful release of this software using >>> this very same technique on that-other-platform-that-shall-not-be >>> named. Things are very smooth and zippy on that platform, but Android >>> currently suffers by comparison. Is there any way to do this? >>> >>> >>> Thanks >>> >>> Glenn >> >> -- 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
