LWJGL Architecture and Performance Question

[Dharcon17]

Hi,

I have some architecture and performance questions and concerns concerning LWJGL, that maybe Matzon or someone else can answer and help me with.

I have been using LWJGL a couple of years now for smaller OpenGL projects. I am currently developing my own game engine and i am considering using LWJGL for the graphics part
of the engine. I love LWJGL , but i am still hesitating to use it in the engine because of some questions and concerns that came up when i looked at the LWJGL source code and i considered doing some bindings on my own, which is stupid because the LWJGL guys did a great job and i don't want to invent the wheel again.

Most of my concerns are performance problems or let's say , i think that those may be performance problems, which i hope you can tell me that these are no problems at all.

With each OpenGL function call there are a lot of checks (Buffer checks and so)  before calling the native method, the function pointer long value is get  and send through to the native code, cast to the function pointer on the native side and at last is gl function is then called, to sum it up a little. Now my question  maybe Matzon can answer is, isn't that a lot of overhead? Why was it implemented like that? Are the buffer checks needed? And why didn't you use something like Glee or Glew for the function pointers instead of holding them on the java side and passing them to the native side all the time?

I am just curious to know about the design and architecture decisions behind LWJGL. Like i said i looked at the source code for a while now. There are still a few things, that i still would love to now, why you implemented it the way you did.

Another thing is, that when i see the rendering part of my engine, the are a parts were a lot of OpenGL calls could be wrapped into a single JNI call, but instead with lwjgl every single opengl call has its buffer checks and so on and the JNI overhead. Would those calls be really overhead, that i can save with wrapping gl calls in a single native method, or are those concerns negligible.

And another important question i have is, that if would like to wrap some functions in a single native code, would there be problems with lwjgl or the opengl context if i would use GLee or Glew on the native side for example. That would be great to now, so that for the most part i would still use the lwjgl gl functions but for some parts i would wrap calls to my own native method.

I would be glad if you could clarify some concerns i have, because i would love to use lwjgl with my engine. It was just the Overhead ( which may be none ), i saw in the buffer checks , JNI calls and so on, that some doubts came up.

thanks in advance,

Mike 





 

[princec]

The overhead of which you speak is microscopic... not even that, it's measured in nanos on newer processors. The bottleneck with any GL application is always geometry or fillrate or both. As you can pipe geometry to OpenGL as fast as C if you use DirectByteBuffers and the fillrate depends entirely on the card you really needn't worry about why all those checks are in there.

The reason the checks are in there is purely to make the library behave like a real, professional Java library, throwing the appropriate and meaningful exceptions without fail when something is amiss, like a missing function. Nearly everything was moved Java-side as well to let the VM take care of the optimisations if it can.

Cas

[Dharcon17]

thanks Cas.

As i feared, i really put to much thought into those concerns, which are just negligible. I just looked at the lwjgl source so often, that i was just curious why you implemented it that way.


thanks again
Mike