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

[Matti Katila]

On Tue, 17 Jan 2006, Benja Fallenstein wrote:
> > I was on the basis that
> > tokenization is orders of magnitude faster than JNI calls, which of course
> > may be totally wrong.
>
> I wouldn't know either :-)

Umh, I not 100% sure what Tuukka suggests but as I understood one string
would be passed to callGL per frame. It sounds a bit overkill even with
stringbuffer.

    str = ""
    for i in coordinates:
        str += "translate "+i.x+" "+i.y+" "+i.z
        str += "scale "+i.sx+" "+i.sy+" "+i.sz

        str += drawVob(i);


> > 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?
>
> Yeah, but we won't know if it's fast enough before we try it, anyway.
> My point was that we can try with the wrapper and if it's not fast
> enough, we can still try with the other system, without having to
> throw away the code we've done so far.

We can always come back to the old implementation if we find a
off-the-self wrapper inadequate to our purpose.


> > 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?

I think that was one of my original points indeed. Having less native code
would run also in humppake's apple.


> More people might feel able to work on the Java version of Libvob/GL
> than the C++ version (hint: me). But using an off-the-shelf wrapper
> would be much preferable. Another reason to try that first. :-)

I agree.


   -Matti