I posted the following to the gcj mailing list (java@gcc.gnu.org). Somebody suggested that I post it here as well. The background is that I recently got jogl working nicely with gcj (an RPM is available for Fedora Core 4 test releases). I thought I'd try my hand at LWJGL.....
---- cut here --------------------------------------
LWJGL provides another OpenGL binding for java among other things (see
lwjgl.org). I was able to build it after a little jawt fixing (patch
coming soon).
Unfortunately it doesn't run. They use a really nasty kludge that
doesn't work with gcj. For some reason,they require access to low-level
graphics info in their java code. The info they need isn't provided by
the high-level interfaces available to normal programs (like in
GraphicsDevice), so they use this trick to call methods on Sun's private
subclasses.
static int getScreenFromDevice(GraphicsDevice device) throws LWJGLException {
try {
Method getScreen_method = device.getClass().getMethod("getScreen", null);
Integer screen = (Integer)getScreen_method.invoke(device, null);
return screen.intValue();
etc
etc
They use this same trick to get a visualID from Sun's private
GraphicsConfiguration subclass.
We will either have to implement similar secret interfaces, or ask the
LWJGL folks to change their ways (if that's even possible), or both.
I don't plan on doing anything more with this right now. This was just
an FYI.
AG
This sounds like something of an AWTGLCanvas issue ?
Using the native display shouldn't involve the java api at all?
that would be nice to see lwjgl compiled with gcj :)
Quote from: "Matzon"This sounds like something of an AWTGLCanvas issue ?
Using the native display shouldn't involve the java api at all?
I'm not all that familiar with lwjgl. What is the "native display"? I see some people are also using lwjgl with SWT - in which case I would avoid this problem as well, correct?
Thanks!
AG
To get LWJGL running with GCJ, you only need 2 things: Support for direct ByteBuffers, support for JNI.
If you want to use the AWTGLCanvas component with GCJ, it might get hairy as this requires AWT component stuff
Quote from: "green"Quote from: "Matzon"This sounds like something of an AWTGLCanvas issue ?
Using the native display shouldn't involve the java api at all?
I'm not all that familiar with lwjgl. What is the "native display"? I see some people are also using lwjgl with SWT - in which case I would avoid this problem as well, correct?
'normal' LWJGL usage just involves the app using the Display class to get a simple OpenGL window to do stuff in. This ends up being created as a native window, totally seperate from any kind of windowing system.
The AWT and SWT bindings are a method of getting LWJGL display embedded within their respective windowing systems, and are not 'common' usage.
I wonder how JOGL gets at the private information, then?
- elias
Looking through JOGLs code they need the same info as we do, but in case it is unavaliable, they simply try and get along without it. I've implemented and comitted similar behaviour to CVS, so could you try it out a second time?
- elias