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

[Tuukka Hastrup]

On Tue, 17 Jan 2006, Benja Fallenstein wrote:
> 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.

[snip]
> 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.

I have to make sure you're not just joking :-) The compilers in question
should perhaps get language simplicity options in addition to optimization
strength options :-) Besides, callgl is more of an interpreter :-) I
forgot to point to callgl/src/callgl.cxx which receives the string on the
native side. There's just tokenization, no backtracking. The int array
interface would remove the tokenization. I was on the basis that
tokenization is orders of magnitude faster than JNI calls, which of course
may be totally wrong.

> > 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.)

You're right, if we are to implement Libvob/GL in Java, it could probably
be pretty independent from the native wrapper. But if this can't be made
fast enough, all the work has been for nothing, right?

Now it might be a gain in itself to have as much of the code in Java and
as little in C++ as possible, but that's not how I understood Matti and
the situation. As long as we need to release some native code someone has
to port it, maintain it, compile it. Would it be a significant change to
have less native code?


Tuukka

-- 
-- Trying to catch me? Just follow up my Electric Fingerprints
-- To help you: address@hidden
                http://www.iki.fi/Tuukka.Hastrup/
                IRCNet: tuukkah/Stugge @#pii,#fenfire,#toys
                Jabber ID: address@hidden, ICQ #11321669