OpenGL ES source files
Question: I am trying to build the OpenGL SO lib from android sources (libGLESv2.so) and
i would like a little bit more understanding of the internal mechanism of
Android OpenGL ES and the flow.

Please correct me where i am wrong: I know that in windows a developer
includes gl.h and static link to OpenGL32(64).lib (which in turn dynamically
link to OpenGL32.dll (probably there is a way to dynamic linke to OpenGL32.dll
by the developer but that's not important). The developer is exposed to the
declaration of OpenGL API's but the implementation which i assume to be HW
dependent.

The same scenario, Android: assuming developer import .opengl.GLES20 and calls
the following method: GLES20.glTexEnvf(.... I would like to know what's going
on behind the scenes in android (maybe Linux is better for an Android
beginner). the implementation which reside in
opengl/java/android/opengl/GLES20.java source calls the native C function
glTexEnvf which unlike windows we have it's implementation which reside in
opengl/libagl.

Is it true? In any case what is the GLES2_dbg library in /libs/GLES20_dbg? i
can see there some kind of debug implementation with python scripts... are
they to compile OpenGL debug version? What are the .in files and gl2.cpp file
in /libs/GLES20? Where are the HW calls? does each GPU vendor sends his
libGLESv2 implementation for HW calls as i saw the libGLESv2_adreno200.so in
my xperia arc?

Please help me understand the flow. If you have a link which explain this
structure even in Linux it will be great.


Answer: In Windows opengl32.dll contains both a software rasterizer fallback and so
called trampolines into the OpenGL-ICD shipping with the GPU driver.

The opengl32.lib ist not really a library but a cross reference for the linker
to add entries into the executable that make the OS dynamically link the
program against the DLL at runtime.

On Linux in the current implementation the libGL.so ships with the graphics
driver and contains the vendor specific implementations. The linkers used in
*nix systems don't rely on an extra crossreferencing .lib but can take the
information directly from the .so

On Android the libGLES you see is only a kind of placeholder to make linking
possible. But ultimately the GPU vendor provides the proper library, which
drops into the place where the phony libGLES resided.

The .in files are nothing special in particular. They are input files used by
configure and build systems to build source files from a template (the .in
file) with fields filled in by configuration values.

