replacing custom jni bindings for jogl

Hi guys,

We currently have our own jni bindings to opengl for our in house renderer. The bindings to opengl are pretty old and have not been updated in a long time. I would like to replace these bindings with jogl. I would not like to change the interfaces from this application level since they are many usages of it higher up in the application.

Can some of you experienced folks give advice on best practices or tips on how you would replace and entire application tier using java bindings to opengl to use jogl underneath it?

Should i look at how gluegen works? I have used jogl only as a hobby and i havent looked deep into its architecture.

Is there a way i can define how the interface should look like to match what we in our renderer?

thanks

On 07/17/2012 05:36 PM, siddharth_univ [via jogamp] wrote:
> Hi guys,
>
> We currently have our own jni bindings to opengl for our in house renderer.
> The bindings to opengl are pretty old and have not been updated in a long
> time. I would like to replace these bindings with jogl. I would not like to
> change the interfaces from this application level since they are many usages
> of it higher up in the application.

You could do a [1] wrapper,
[2] a custom binding requiring you to create your custom JOGL
[3] or change your code .. which you don't like.

Since we don't know how much your current binding looks like
no statement can be given about the costs of [2].

>
> Can some of you experienced folks give advice on best practices or tips on how
> you would replace and entire application tier using java bindings to opengl to
> use jogl underneath it?

Many use some agnostic wrappers, read: delegation to JOGL.

>
> Should i look at how gluegen works? I have used jogl only as a hobby and i
> havent looked deep into its architecture.

Look at GlueGen's unit tests .. I guess thats a good start.
There is one detailed binding test .. generation and validation
of GlueGen itself.

>
> Is there a way i can define how the interface should look like to match what
> we in our renderer?

Depends ..

Even for [1] you could use GlueGen to create a wrapper,
see how TraceGL* is created.

Currently the naming solely depends on:
  - the header files
  - the build-in type explosion: arrays, NIO-buffer, ..

However, I doubt it's more cost effective to do [1] or [2].
Don't underestimate the costs of testing and fixing regressions.
JOGL, as-is, is well tested on all supported platforms
via our CI - have a look at our Jenkins build server.

[3] seems to be the most safe way, you can even try to use
and automatic conversion w/ jackpotc, see 'jogl/tools/jackpotc'.

(We haven't tested conversion using jackpotc for a long time though ..)

>
> thanks
>

Hope that helps a bit.

~Sven

On 07/17/2012 06:20 PM, Sven Gothel wrote:
>

<snip/>

> You could do a [1] wrapper,
> [2] a custom binding requiring you to create your custom JOGL
> [3] or change your code .. which you don't like.
>
> Since we don't know how much your current binding looks like
> no statement can be given about the costs of [2].
>

<snip/>
Further more, JOGL employs partial GL state tracking
allowing no-roundtrip queries, validation for correctness
and implementing certain features profile and platform agnostic.
The latter includes debug/trace, GLX/WGL/.. aliasing
and the currently in development API-transparent FBO offscreen rendering.

>
> [3] seems to be the most safe way, you can even try to use
> and automatic conversion w/ jackpotc, see 'jogl/tools/jackpotc'.
>
> (We haven't tested conversion using jackpotc for a long time though ..)
>

hi sven,

thanks for your reply.

I was searching for "delegation to JOGL" in the wiki but could not find it. Do you have a url to it?

Thanks for your tips, i will go through one by one of your suggestions and if i have any questions, then i will post it in this thread.

-Siddharth