GLJPanel for LibGDX JOGL backend

I'm working on a LibGDX project with JavaFX.  I've followed the trail of GLJPanel, GLJFXPanel, as well as projects like LWJGL-FX, and even opened an issue on LibGDX asking for the very same thing stated in the title. The trail led me here since, apparently, the LWJGL backend for LibGDX was written by you all

Since it was stated that GLJPanel -> SwingNode -> JavaFX allows rendering, would it be possible to create a port for LibGDX? Currently, while LWJGLCanvas is embeddable, it doesn't show anything.

Thanks.

No, JOGL is another binding to OpenGL than the one you mention.
There is a JOGL backend for libGDX: http://forum.jogamp.org/JOGL-2-0-OpenGL-OpenGL-ES-backend-for-LibGDX-td4027689.html

jmaasing is right. You dare to disturb us by mentioning a competitor...

Aaaagh! I see. Really sorry, it was a long day yesterday, I didn't even know a project like LWJGL existed , I thought the JGL in the acronym meant JOGL , especially when I got things crossed reading that post linked to above (I read it before jmaasing brought it up). Very embarrassing.

In any case, the need / want is still there. Somehow, GLJPanel is the only working solution for getting a display on SwingNode, how feasible would it be to contribute it to the existing JOGL backend for LibGDX?

Actually, even JGLFW has nothing to do with JOGL and it is used in another backend of LibGDX.

adam_law wrote

I thought the JGL in the acronym meant JOGL

adam_law wrote

In any case, the need / want is still there. Somehow, GLJPanel is the only working solution for getting a display on SwingNode, how feasible would it be to contribute it to the existing JOGL backend for LibGDX?

You need to implement an equivalent of JoglAWTCanvas but based on GLJPanel. Let me know whether you need some help.

adam_law wrote

I'm working on a LibGDX project with JavaFX.  I've followed the trail of GLJPanel, GLJFXPanel, as well as projects like LWJGL-FX,...

There is a port of LWJGL-FX rewritten to use JogAmp JOGL available at:
https://github.com/AqD/JOGL-FX

I have not tested this port but maybe it will work for your use-case.

thanks for enlightening me :)

Where's the main source for JOGLAwtCanvas? Search results show it to be from jMonkeyEngine? I'll take a crack at it, but right now, we're a bit pressed for time :(

@Xerxes
thanks for the link. It seems that it was based of a slightly older commit from spasi's LWJGL-FX project, and maybe that's why we passed it over before. In any case, this will be what we'll evaluate today :))

adam_law wrote

Where's the main source for JOGLAwtCanvas? Search results show it to be from jMonkeyEngine? I'll take a crack at it, but right now, we're a bit pressed for time :(

You were talking about LibGDX. Rather look for it in Github:
https://github.com/gouessej/libgdx/blob/master/backends/gdx-backend-jogamp/src/com/badlogic/gdx/backends/jogamp/JoglAWTCanvas.java

Oops. Thanks Google

Thank you for the point-out, Julien. I've also done what I should have at first and researched more on the the terms brought up here. I am now clear on what JOGL, LWJGL, and JGLFW are, and I'm suitably impressed at how prolific you guys are.

I think one of the reasons I missed the JOGL backend was that it's not yet merged with the official LibGDX project? From what I've read just now, there's a flurry of activity that got the backend up to LibGDX 1.6.2, and there will be a Maven tree up soon with a pre-compiled jar. I think I'll wait for that, if it's coming soon. I tried adding the line for the backend to my gradle build, but it seems that the resource is no longer available e.g. compile "com.badlogicgames.gdx:gdx-backend-jogamp:1.5.6-SNAPSHOT".

Out of curiosity, I gather JOGLAwtCanvas is not suitable for embedding into SwingNode? Heavyweight?

Thanks, this is getting very interesting :)

adam_law wrote

I think one of the reasons I missed the JOGL backend was that it's not yet merged with the official LibGDX project?

It will be probably never merged into the official LibGDX project but it doesn't prevent anybody from using it. If you really need something "official", you will never use our stuff. We can't force the LibGDX maintainers to accept our pull requests.

adam_law wrote

From what I've read just now, there's a flurry of activity that got the backend up to LibGDX 1.6.2, and there will be a Maven tree up soon with a pre-compiled jar. I think I'll wait for that, if it's coming soon. I tried adding the line for the backend to my gradle build, but it seems that the resource is no longer available e.g. compile "com.badlogicgames.gdx:gdx-backend-jogamp:1.5.6-SNAPSHOT".

Maybe Xerxes knows why.

adam_law wrote

Out of curiosity, I gather JOGLAwtCanvas is not suitable for embedding into SwingNode? Heavyweight?

I can't confirm. I use OpenJDK and I don't have OpenJFX available on my distro yet. Just give it a try and let us know.

gouessej wrote

adam_law wrote

I think one of the reasons I missed the JOGL backend was that it's not yet merged with the official LibGDX project?

It will be probably never merged into the official LibGDX project but it doesn't prevent anybody from using it. If you really need something "official", you will never use our stuff. We can't force the LibGDX maintainers to accept our pull requests.

adam_law wrote

From what I've read just now, there's a flurry of activity that got the backend up to LibGDX 1.6.2, and there will be a Maven tree up soon with a pre-compiled jar. I think I'll wait for that, if it's coming soon. I tried adding the line for the backend to my gradle build, but it seems that the resource is no longer available e.g. compile "com.badlogicgames.gdx:gdx-backend-jogamp:1.5.6-SNAPSHOT".

Maybe Xerxes knows why.

Trying to combine atrifacts from two different builds using two differrnt version numbers is not recommended, it may work but it is not something that jogamp or libgdx can support. Instead i reccomend that you do the following:

The latest JOGL libgdx port is in sync with LibGDX 1.6.3-SNAPSHOT
if you checkout gouessej's libgdx master tree

git clone https://github.com/gouessej/libgdx
cd libgdx

and run

mvn install

you will build both libgdx 1.6.3-SNAPSHOT and gdx-backend-jogamp 1.6.3-SNAPSHOT and install them both into your own local maven repository.

I highly recommend that you use the combination of libgdx and gdx-backedn-jogamp artifacts produced from one build because that is a combination that we can support.

Inside your applications projects build.gradle file you then add mavenLocal() to the list of repositorys
and use 1.6.3-SNAPSHOT as the version of libgdx you want to use.

If your build.gradle file looks like this then you will always use the latest libgdx + jogamp backend snapshot version from your local maven repository!

<code>
import groovy.json.JsonSlurper

buildscript {

    ant.get(src: 'http://libgdx.badlogicgames.com/libgdx-site/service/getVersions?release=false', dest: 'versions.json')
    def versionFile = file('versions.json')
    def json
    if (versionFile.exists()) {
        json = new JsonSlurper().parseText(versionFile.text)
    } else throw new GradleException("Unable to retrieve latest versions, please check your internet connection")

    ext {
        gdxVersion = json.libgdxSnapshot
        roboVMVersion = json.robovmVersion
        roboVMGradleVersion = json.robovmPluginVersion
        androidToolsVersion = json.androidBuildtoolsVersion
        androidSDKVersion = json.androidSDKVersion
        androidGradleToolsVersion = json.androidGradleToolVersion
        gwtVersion = json.gwtVersion
        gwtGradleVersion = json.gwtPluginVersion
    }

    repositories {
        mavenLocal()
        jcenter()
        mavenCentral()
        maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }
    }

}

allprojects {
    apply plugin: "eclipse"
    apply plugin: "idea"

    version = "1.0"
    ext {
        appName = "Pax-Britannica"
    }

    repositories {
        mavenLocal()
        mavenCentral()
        maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }
    }
}

project(":core") {
    apply plugin: "java"

    dependencies {
        compile "com.badlogicgames.gdx:gdx:$gdxVersion"
    }
}

project(":desktop") {
    apply plugin: "java"

    dependencies {
        compile project(":core")
        compile "com.badlogicgames.gdx:gdx-backend-jogamp:$gdxVersion"
        compile "com.badlogicgames.gdx:gdx-platform:$gdxVersion:natives-desktop"
    }
}

tasks.eclipse.doLast {
    delete ".project"
}
</code>

Xerxes is right and the version of LibGDX on my repository is only about 10 commits behind the "official" one.

gouessej wrote

It will be probably never merged into the official LibGDX project but it doesn't prevent anybody from using it. If you really need something "official", you will never use our stuff. We can't force the LibGDX maintainers to accept our pull requests.

I fully understand, stability, currency in a working solution are much more important to me than adhering to anything official :)
 

gouessej wrote

I can't confirm. I use OpenJDK and I don't have OpenJFX available on my distro yet. Just give it a try and let us know.

I will within today or tomorrow.

"Xerxes wrote

Trying to combine atrifacts from two different builds using two differrnt version numbers is not recommended, it may work but it is not something that jogamp or libgdx can support. Instead i reccomend that you do the following:

The latest JOGL libgdx port is in sync with LibGDX 1.6.3-SNAPSHOT
if you checkout gouessej's libgdx master tree

git clone https://github.com/gouessej/libgdx
cd libgdx

and run

mvn install

you will build both libgdx 1.6.3-SNAPSHOT and gdx-backend-jogamp 1.6.3-SNAPSHOT and install them both into your own local maven repository.

I highly recommend that you use the combination of libgdx and gdx-backedn-jogamp artifacts produced from one build because that is a combination that we can support.

Inside your applications projects build.gradle file you then add mavenLocal() to the list of repositorys
and use 1.6.3-SNAPSHOT as the version of libgdx you want to use.

If your build.gradle file looks like this then you will always use the latest libgdx + jogamp backend snapshot version from your local maven repository!

gouessej wrote

Xerxes is right and the version of LibGDX on my repository is only about 10 commits behind the "official" one.

Thanks for the detailed steps. I actually already checked out gouessej's master tree earlier today, and modified my gradle build to use this libgdx version for my project, to test the backend. I've been writing correspondence and doing other stuff, so I haven't been able to sit down and have a go at it yet. I'm excited to try once I get back home. I'll let you all know how it goes :)

I just dropped by for an update. As I suspected, JOGLAwtCanvas doesn't work. SwingNode expects content of type JComponent. I've tried start to write an extension for GLJPanel; I did it from within my project, for a quick start, but, apparently, several methods and members of JoglApplication are accessible on the package level only. So I started again by doing this in the backend package, from the source I checked out from goussej's master tree, but I have encountered an issue where the gdx-natives.jar seems to be not included in the gdx project(?) I believe I used to have it within the system, but after running mvn install for jogamp version of libGDX, I can't seem to find it on either maven local, or the gradle cache. I'll try to look for a downloadable jar somewhere. maven central doesn't have it.

You probably have to generate this JAR. I can still run the examples without any trouble.

yeah, I was able to nab a copy from the libgdx nightlies.

I've given it a shot, implementing LibGDX' Application and using pretty much the standard initialization that was in JoglApplication. I then had a GLJPanel member add an instance of NewtCanvasAWT(graphics.getCanvas()) to itself and I then added this GLJPanel to a SwingNode. Unfortunately, I get an error:

Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: Width (0) and height (0) cannot be <= 0
        at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1016)
        at java.awt.GraphicsConfiguration.createCompatibleImage(GraphicsConfiguration.java:186)
        at sun.awt.image.SunVolatileImage.getBackupImage(SunVolatileImage.java:236)
        at sun.awt.image.VolatileSurfaceManager.getBackupSurface(VolatileSurfaceManager.java:263)
        at sun.awt.image.VolatileSurfaceManager.initialize(VolatileSurfaceManager.java:126)
        at sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:88)
        at sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:117)
        at java.awt.GraphicsConfiguration.createCompatibleVolatileImage(GraphicsConfiguration.java:307)
        at java.awt.GraphicsConfiguration.createCompatibleVolatileImage(GraphicsConfiguration.java:241)

I checked the dimensions of both SwingNode and the GLJPanel, and these weren't the culprits. I couldn't trace back as I don't have the source of some parts of that stack trace.

Any thoughts of my implementation and the error?

Edit: Forgot to add, letting the application continue, I get this next, where JoglPanel is the name of the custom class I wrote:

Exception in thread "JavaFX Application Thread-AWTAnimator#00" com.jogamp.opengl.util.AnimatorBase$UncaughtAnimatorException: com.jogamp.opengl.GLException: Caught ClassCastException: com.badlogic.gdx.backends.jogamp.JoglPanel cannot be cast to com.badlogic.gdx.backends.jogamp.JoglApplication on thread JavaFX Application Thread-AWTAnimator#00
        at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:84)
        at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:451)
        at com.jogamp.opengl.util.Animator$MainLoop.run(Animator.java:198)
        at java.lang.Thread.run(Thread.java:745)
Caused by: com.jogamp.opengl.GLException: Caught ClassCastException: com.badlogic.gdx.backends.jogamp.JoglPanel cannot be cast to com.badlogic.gdx.backends.jogamp.JoglApplication on thread JavaFX Application Thread-AWTAnimator#00

I'm using Java 8 64-bit.

Edit #2: On one of your old posts, it mentioned people using GLJPanel successfully with SwingNode, would you happen to know where there might the code snippet for that?

Edit #3: I was able to circumvent the IllegalArgumentException by setting the canvas size at start based on a clue found here. I used a modified version of JoglAWTCanvas since it was quicker for troubleshooting. I will amend the JoglPanel I wrote to extend JoglApplication instead of implementing Application, to fix the
ClassCastException.

While there no longer any errors when I used the modified JoglAWTCanvas, nothing is displaying. I'll try modifying JoglPanel and try that.

Edit #4: I broke through About a minute after my last edit, I remembered that I can't simply extend JoglApplication. It creates a NewtWindow in the process, running alongside my JavaFX based app.

I guess I'm getting close ? I see in JoglGraphicsBase that the GLWindow is created automatically, which I prevent by overriding JoglApplication's initialize and not setting graphics.getCanvas().setVisible() to true. Right now it's a black are where the embedded GLJPanel is within the SwingNode. Did I do the right bthing by not setting the canvas to visible? If it needs to be visible, how do I access what needs to be drawn on the GLJPanel without spawning a window? I also notice a hiccup / slowdown at startup, and this is true when I launch my app w/o the JavaFX parts as a JoglApplication.

Lastly, is there a need to override GLEventListener if this ever gets working?

Thanks.

Edit #5: Out of curiosity, I tried hooking up the canvas' GLEventListener to the GLJPanel via gljpanel.addGLEventListener(graphics.getCanvas().getGLEventListener(0)). Spat out an error where it failed the check for current context:

Caused by: com.jogamp.opengl.GLException: AWT-EventQueue-0: This context is not current. Current context: WindowsWGLContext

No comment?

Please publish your modified code with instructions how to setup and run the code to experience the exceptions.

Sure. I just followed goussej's advice and came up with this.

I then just add it to a SwingNode by adding JoglPanel.getPanel() in SwingNode.setContent(), after passing a LibGDX ApplicationListener instance.

Maybe it would be better to extend JoglGraphicsBase, replace GLWindow by GLJPanel and extend JoglAWTCanvas, use JoglAWTInput instead of JoglInput. I'm sorry, LibGDX isn't currently the best solution to interoperate with JavaFX but we might succeed in solving your issue.