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

Reply via email to