aboutsummaryrefslogtreecommitdiffstats
path: root/src/java/com/sun/gluegen/opengl/BuildComposablePipeline.java
diff options
context:
space:
mode:
authorKenneth Russel <[email protected]>2009-05-20 21:45:40 +0000
committerKenneth Russel <[email protected]>2009-05-20 21:45:40 +0000
commit06fd97a1343718c6949b0408108f4c3124420299 (patch)
treee42f35a8945effeadbac2510be96dbdb0afd847c /src/java/com/sun/gluegen/opengl/BuildComposablePipeline.java
parent1351343c7065f0ebbb9a3597c90a740498b2e7eb (diff)
Recently code (UnifiedName, GLUnifiedName) was added to GlueGen to
automatically detect duplicate constant and function definitions between vendor and ARB extensions and the OpenGL core, and to remove the suffixes of ARB extensions. This code has helped automate the process of discovering extensions that were promoted into the OpenGL core. While this code has saved some manual effort, it has also caused several problems: 1. It causes obsolete ARB extensions to be incorrectly moved into the core OpenGL namespace. GL_ARB_texture_rectangle, GL_ARB_vertex_blend, and GL_ARB_matrix_palette are examples of extensions that should not have their ARB suffixes removed because they are dead-end extensions. Definitions which are explicitly specified that they will change, such as those in the EGL_KHR_sync extension, were also incorrectly moved into the core namespace. 2. It has caused certain OpenGL ES-specific definitions to accidentally be promoted into the core OpenGL namespace: for example, the constants associated with the GL_OES_point_size_array extension, which were incorrectly placed into the GL2ES1 interface. 3. It causes namespace collisions between certain ARB extensions that are only accessible via their ARB entry points and core OpenGL routines: specifically GL_ARB_vertex_program and GL_ARB_fragment program. Based on tests on NVIDIA's drivers, when a developer wants to use the earlier ARB_vertex_program and ARB_fragment_program semantics rather than GLSL, it is mandatory to use the ARB entry points rather than the core OpenGL entry points. 4. It is not easy to configure the behavior of this automatic merging, nor easy to see how it would be extended to be configurable. 5. It does not address the problem of detecting which extensions are common between desktop OpenGL and OpenGL ES. A different algorithm would be needed to solve that problem. 6. It has a high degree of functional overlap to the IgnoreExtension directive which has previously been used to ignore ARB extensions that were promoted into the OpenGL core. There were already IgnoreExtension directives in place for all of the OpenGL extensions subsumed in OpenGL 1.1 through 1.3. 7. It has been the cause of several bugs and unexpected interactions with the Ignore and ForceProcAddressGen directives. After careful consideration, it appears that the problems with this code outweigh the benefits and it has been removed. The run-time code which attempts to find extension variants of core entry points has been retained, however. To reduce the amount of subsequent manual work, the following additions have been made: 1. A generic SymbolFilter mechanism has been added to GlueGen, which can be used to pre-process the entire set of constant and function definitions at any time during glue code generation (although it is recommended to do so at the beginning of processing, i.e., in GlueEmitter.beginEmission()). 2. The RenameJavaMethod directive has been generalized to RenameJavaSymbol, and can now work on constant definitions. 3. A ConstantDefinition class has been added. 4. A RenameExtensionIntoCore directive has been added to the GLEmitter which will rename all constant definitions and entry points associated with a particular OpenGL extension into the core namespace, i.e., stripping off any ARB or similar suffixes. 5. An AutoUnifyExtensions directive has been added which is disabled by default but which will automatically ignore any OpenGL extension which has been completely subsumed into the OpenGL core and, if not, print out the first declaration in that extension which caused it to fail to be ignored. The extensions common between OpenGL ES and desktop OpenGL have now largely been moved into the core namespace using the RenameExtensionIntoCore directive. A couple of these extensions had slight differences between desktop OpenGL and OpenGL ES; the common declarations were renamed manually. IgnoreExtension directives have been added for those ARB extensions promoted into the OpenGL core up to OpenGL 2.1. A few extensions which were either silently promoted into the core specification (GL_EXT_paletted_texture) or are obsolete (GL_EXT_multisample, GL_EXT_point_parameters) were also ignored. The GlueGen runtime code which looks up extension versions of core APIs via GLExtensionNames makes this possible without breaking compatibility on older machines that do not support OpenGL 2.1 directly. With these changes, the same effect as the automatic extension unification mechanism has been achieved, with much more explainable and controllable results. Before-and-after versions of all of the public interfaces (GL, GL2ES1, GL2ES2, GLES1, GLES2, and GL2) have been compared by hand to ensure that the results are as expected and desired. Bugs in BuildStaticGLInfo were fixed which were preventing the extension associations in the OpenGL ES headers from being discovered. getExtensions() was added to be able to enumerate the discovered extensions. Most .cfg files were changed to parse both the desktop OpenGL and the OpenGL ES headers using the GLHeaders directive so that the extension associations are known for both sets of APIs. git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/../svn-server-sync/gluegen/branches/JOGL_2_SANDBOX@134 a78bb65f-1512-4460-ba86-f6dc96a7bf27
Diffstat (limited to 'src/java/com/sun/gluegen/opengl/BuildComposablePipeline.java')
0 files changed, 0 insertions, 0 deletions