The only way you can do this safely is from a thread that has your EGL context as the current context. Using a lock is not going to help, what matters is being on a thread with a GL context attached. The OpenGL ES spec is pretty clear about this.
To achieve what you want you should use a SurfaceTexture or an EGLImage. On Sun, Jul 1, 2012 at 7:04 AM, gl...@wanderfulstorybooks.com < gl...@wanderfulstorybooks.com> 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, >> gl...@wanderfulstorybooks.com 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 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 -- 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