Why Does a GL Thread Behave Like a Normal Thread? Unraveling OpenGL ES on Android

1. OpenGL ES Drawing Complete Process

Android abstracts the complex OpenGL ES drawing pipeline, exposing a simplified workflow to developers. The full process includes obtaining the display device (EGLDisplay), initializing EGL, choosing an EGLConfig, creating an EGLContext, acquiring an EGLSurface, making the context current on a thread, and finally issuing draw calls.

(1)

(2)

(3)

(4)

(5)

(6)

After these steps, the rendering logic runs, typically inside the onDrawFrame() callback of GLSurfaceView.

2. GLSurfaceView Internals and EGL Logic

Inside GLSurfaceView there is a GLThread class that extends Thread. Its guardedRun() method performs the same steps as the full pipeline, invoking onSurfaceCreated(), onSurfaceChanged(), and onDrawFrame(). Thus a GL thread is essentially a normal thread that follows the OpenGL drawing sequence, granting it OpenGL capabilities.

3. How EGL Enables OpenGL

OpenGL functions such as GLES20.glGenTextures() and GLES20.glDeleteTextures() are native and static. They operate on the EGL context that is thread‑specific (Thread Local). When eglMakeCurrent() is called, the EGL context is stored in the calling thread’s “storage locker”. Only the thread that holds that context can access the textures created within it.

Key points:

Each thread has its own EGL context (Thread Specific).

A context cannot be made current on two threads simultaneously.

Calling eglMakeCurrent() with a different context detaches the previous one.

Textures are bound to the EGL context, not to the thread. When a GL thread is destroyed, if its EGL context is also destroyed (as happens with GLSurfaceView), the textures are freed; otherwise they remain.

4. Summary of Core Questions

What is the difference between a GL thread and a normal thread? None in essence; a GL thread simply follows the full OpenGL pipeline, granting it rendering ability.

Are textures bound to the GL thread? No, they are bound to the EGL context.

Why can’t a texture created in one GL thread be used in another? Because each thread has its own EGL context, and textures reside in that context.

Why do textures disappear when a GL thread is destroyed? Typically the associated GLSurfaceView destroys the EGL context, which also frees its textures.

How can different threads share OpenGL data? By creating a shared EGL context via eglCreateContext() with a share context, or by unbinding a context from one thread and binding it to another.