Hmm I hadn't thought about the prefix stuff yet. Good point.
You could call your object 'gl' which gives you gl.ProgramEnv... :)
The only way I know to dynamically get all these methods into one object
is to use Proxy, but I don't think this would be very efficient.
So, so far we have:
+ Small memory saving
+ No noop methods
+ Flexible extensibility
- Prefixes before methods
Pepijn
Alban Cousinié wrote:
> Hi Pepijn,
>
> This mechanism is interesting as it is allowing to save memory while
> avaoiding loading the extensions not needed. The only thing that annoys
> me is the fact that we would have to prefix every call to a
> vertexProgram function by the variable name "vertProg.", so in your
> sample, we'd have code like :
> vertProg.ProgramEnvParameter4dvARB(args);
> On the other hand, the memory saved (a few Kilobytes) is not very
> interesting on personal computer context. On a PDA or a global phone,
> the gain would be much more interesting.
>
> If we are using, say, 8 different extensions, we'd have to keep in mind
> every prefix, which is not easing the programming task. The current
> mechanism is more ergonomic because you always prefix your function
> calls by "gl" and nothing else, thus you don't have to remember these
> extensions class names.
>
> Ideally, removing any prefix would be the best solution as it would
> allow easier porting from c++ OpenGL code (that has no prefix) to
> gl4java code, but I don't think this is possible with Java, as a class
> cannot be declared static (except if it is an inner class : see article
> http://www.javaworld.com/javaworld/javaqa/1999-08/01-qa-static2.html)
>
> Anyone have any idea if this could possibly be achieved?
>
> Alban
>
>
> -----Message d'origine-----
> De : gl4...@li...
> [mailto:gl4...@li...] De la part de
> Pepijn Van Eeckhoudt
> Envoyé : dimanche 11 mai 2003 12:10
> À : gl4...@li...
> Objet : [gl4java-usergroup] OpenGL Extensions
>
> I've been trying to come up with a clean mechanism to handle extensions
> in OpenGL. The current solution is to throw all methods and tokens
> (core OpenGL and extensions) into one big class. This leaves you with a
> class that has many methods that simply do nothing. I'm hoping we can
> do better than this.
> The best solution I've been able to come up with is the following:
> - We keep the GLFunc class but it only contains the core OpenGL
> functions and tokens
> - For each extension we provide a class that contais the necessary
> methods and tokens. This extension class can then be loaded if a user
> needs it. I've made a dummy example for the vertex program extension
> (not 100% correct, but it's a good illustration.
> If this is the way to go it might be a good idea to do the same loading
> type mechanism for the core functions as well, for consistency's sake.
> You're application would then be responsible for creating an instance
> of GL, GLU, and any other extension objects and maintaining them. This
> would have to be done in the init method, because the GLContext object
> must already have been created.
>
> Example:
> private GL gl;
> private GLU glu;
> private ARBVertexProgram vertProg;
>
> public void init(GLDrawable gld) {
> GLContext context = gld.getContext();
> gl = GL.createNewInstance(context);
> glu = GLU.createNewInstance(context);
> vertProg = ARBVertexProgram.loadExtension(context);
> }
>
> I would love to here some other ideas and feedback about this.
>
> Pepijn
>
> P.S. Maybe we should move our development discussions to the devel
> list...
> Alex: sorry I ended up playing Metroid Prime all night. Damn Nintendo :)
>
|
