http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
Now, let me ask a question, since LWJGL is calls OpenGL through C, is it possible to do JNI calls directly to the OpenGL as discussed in this article?
As far as I understand it requires major hacking to get this work, but is it actually possible or even worth it if a person has incredible amount of time to waste away?
Uhm… I am not entirely certain of what you’re getting at…
but all of the gl/al code is simple passthru of arguments from Java.
Well, that’s not exactly what we’re doing but we’re very similar. Our OpenGL calls are passed straight on down to their C calls. That’s why we haven’t got array versions of the methods etc.
Cas 
Hmm… I was just wondering is it possible to call a function directly with JNI from the openGL library. Although the C overhead is tiny, it would be possible wouldn’t it? Let’s say if someone were smart enough to hack OpenGL the way they did with windows code at SWT. Basically it would be a lot easier, but more time consuming as you’d have to write JNI function for every single openGL call.
As the article discusses, the operating system is very primitive, and that is how OpenGL is, except that the functions are the same on each of the platforms. However, the problem I see now is that how OpenGL was coded initially. By doing this, we could get rid of the Sys.getDirectBufferAddress and the idea of buffers and reduce one level of overhead as well as call directly from JNI.
So instead of calling C you’d call directly from opengl32.lib and glu32.lib and let the JNI do its work. Would this be possible? As far as I understood the article it is.
I’m interpreting this through that article and I could be talking out of my ass.
Edit: This way we could also take advatange of JNI type handling functions…
Indeed you are
We’re doing it the bestest, fastest, easiest way possible. In theory we could go the whole hog like with SWT and push our OS idiosyncracies up into Java as well but I have a general aversion to OS-specific classfiles. But that can be solved using interfaces and private implementors anyway. It’s an idea that’s probably worth considering because it would likely make our code maintenance that much simpler.
What do you think Elias?
Basically we’d need an “OS” interface with all the OS calls we do, and then we’d just simply move all our native code into private Win32/Linux/MacOS classes. And then we’d need a bridge interface between our public APIs and private APIs - so the Window class’s create() method, for example, called WindowWin32.create(), which in turn called all sorts of Win32 functions directly.
It’d certainly have the advantages outlined in the article.
Just a thought.
Cas
I know you are doing the [insert positive adjective here] graphics library around, but it was just a thought. To tell the truth every time I call Sys.getDirectBufferAddress, I’m first of all ashame of doing it and besides it hurts my brain so hard, due the fact that it is not the most elegant way of getting around.
Secondly, someone(I?) could probably write a proper vector maths library, since to tell the truth I’m not very keen on the current one. For example, it is missing conversion to euler angles, quaternions and rotations. I hate to have my own classes around for most trivial tasks that the library could do. Also I know quite a few optimizations so there might be a speed increase(although I can’t quarantee that).
I’m pretty sure a lot of people like it how it is, but… anyway.
If you’d like to contribute some more vecmath classes to the package we’re especially happy to have them
Cas
Hey Cas, just out of curiousity, what’s all the fixed point math in SPGL for? Floating point is natural to GL, plus floating-point processors make fixed point almost unnecessary. (Well, in 3D anyway. :)) Is there some specific optimization you’re trying to achieve? BTW, neat idea on the 16 bit rotation system. It reminds me of the days when I was using a 256 degree rotation system so I wouldn’t have to bounds check an unsigned byte.
[quote]Indeed you are
What do you think Elias?
Basically we’d need an “OS” interface with all the OS calls we do, and then we’d just simply move all our native code into private Win32/Linux/MacOS classes. And then we’d need a bridge interface between our public APIs and private APIs - so the Window class’s create() method, for example, called WindowWin32.create(), which in turn called all sorts of Win32 functions directly.
It’d certainly have the advantages outlined in the article.
Just a thought.
Cas
[/quote]
I’m not perfectly with you here - you want to create a jni functions for every native function we call, and kill the functions, like Window.nCreate, that does a lot of work on the C side? In a way, do the work on the java side, and make every jni function a callthrough, like the gl calls. If so, I’m still not convinced that this would be a win in the long run - we have very few non-trivial jni functions anyway, but those we have call a lot of native window system functions once or maybe twice. So what’s the win?
I’ll work with over the week end. However, my style is totally different from the current vecmath style, but I can leave mine as 100% compatible alternative.
Another thing I have different is that is store matrices and vertices as an arrays so Matrix4f is basically OpenGL matrix, this is to minimize the overhead, but I can put there access to all the cells if someone wants that, the only problem though is that if they are non static methods and thus they increase the memory cost of the object.
Basically I have one class Math3d, which has all the static functions such as multiplication and because java allows ambigious functions. the classes itself have their own funtions such as Matrix4f.buildEuler(vector3f v) and so on.
Also I’d like to know what the users want. I mean if people like the current ones then there is no point changing them, Just those who want can take the new one.
I can provide a set of math classes that I have more or less copied from Crystal Space. Euler angles and quaternions are still missing, but that should be simple. Apart from that, it got 2d and 3d vectors, matrices, planes, 3d transforms, axis-aligned boxes and an interface to parametric lines and surfaces.
The real point however is that all classes are IMMUTABLE like String. I know that this will hit you because it means lots of allocations all the time. On the other hand it makes coding very clean and makes optimizations possible which are not possible with mutable classes. (For example, you never need to copy a 3d vector).
My intention was to use these immutable classes until they prove to be a bottleneck, and then introduce mutable variants (like StringBuffer) for the inner calculations but still use the immutable variants where possible. Has anyone made real experience with the performance of such an approach?