Re: [Fenfire-dev] Yet another libvob API: LWJGL

[Benja Fallenstein]

Hi Tuukka--

On 1/16/06, Tuukka Hastrup <address@hidden> wrote:
> On Sun, 15 Jan 2006, Benja Fallenstein wrote:
> > Sounds to me like a) a potentially good idea and b) something we don't
> > need to worry about yet, since it will be pretty easy to slap on
> > later?
>
> a) "CallGL - call OpenGL functions from a string"
>    The JNI part is at libvob/src/jni/Main.cxx and
>    libvob/org/nongnu/libvob/gl/GL.java. You can't use callgl alone from
>    Java but lwjgl could include it if they wanted to.

Of course, I may be misunderstanding, but from my understanding,
CallGL would be much to slow for this. My understanding is that it is
used to set up a vob when it is created; it creates a display list for
that vob. My understanding is that it is NOT used for individual
frames. (Of course, we'd use display lists in a Java implementation of
Libvob/GL, too, but there are, obviously, GL calls that are different
between frames.)

Nor do I think that string parsing could be made fast enough for this,
remembering that I've been told parsing is the slowest part in a
compiler. :-)

However, even if I understand it all correctly, that doesn't mean that
this is a bad idea -- as Matti mentioned, we could pass the stuff
through an int array. Just means that we cannot just use the existing
CallGL.

> b) You will need a native implementation on the native side, so if you use
>    one, there isn't much of a point using yet another native part such as
>    lwjgl (which was the subject of this discussion).

True, if we can't get them to integrate the code, but my point is that
we can start with an existing library and if it is too slow, it won't
be more work to write this thing then than it would be to write it
beforehand. (Meaning, I imagine the Java code using it would -- should
-- look the same, except for the 'flush' call in UpdateManager.)

- Benja