| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and this build.
You can say -Drootrel.build=build-x86_64 for example.
- Fixed jogl-demos in regard to this changeset
- Gluegen
- Fixed gluegen BuildComposablePipeline's 'getGL*' methods.
Now they return 'this', otherwise the pipeline would be broken/removed.
- Add BuildComposablePipeline CustomPipeline, which allows customized
class composition with an interface (to be wrapped),
prolog class and the downstream class.
- Add GlueGen (incl. ant task) 'outputRootDir' to be able to set a
top output root dir via ant / commandline.
- GL fixed function
- Package 'javax.media.opengl.sub.fixed.*' defines some fixed function interfaces.
This allows partitioning of custom implementation.
- Using gluegen's new CustomPipeline to compose a GLFixedFuncIf implementation,
using a GL downstream and a GLFixedFuncHookIf prolog.
The latter implements the fixed functionality.
Example is the GLFixedFuncImpl.
gl.getContext().setGL( new GLFixedFuncImpl(gl, new FixedFuncHook(gl.getGL2ES2())) ) ;
or
gl.getContext().setGL( new GLFixedFuncImpl(gl, gl.getGL2ES1()) ) ;
- The example GLFixedFuncHookIf impl FixedFuncPipeline/
can be instantiated with custom shader code.
- ES2 and all other interfaces only contain the original functionality,
besides minor convenient data access methods.
- Fix: GL2ES2 createCompileShader() and createLoadShader() is moved to ShaderCode util class.
- Updated PMVMatrix
- Add: GLAutoDrawable.setContext() .. and all it's implementations
Necessary to set a new GLContext.
- Add: GLContext getAttachedObject(int) and putAttachedObject(int, Object),
to allow the user to attach application specific and TLS sensitive objects to the GLContext.
-
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/../svn-server-sync/gluegen/branches/JOGL_2_SANDBOX@122 a78bb65f-1512-4460-ba86-f6dc96a7bf27
|
