GLJPanel for LibGDX JOGL backend

Thanks for helping me out. I appreciate it :)

Well, I tried as you said and extended these classes, and hooked it up to a SwingNode. Actually, I opted not to extend, chose to implement Application in the line of JoglAWTCanvas and Graphics and GLEventListener, in the line of JoglGraphicsBase with GLJPanel.

Everything passed through creation fine, but it's now saying that the my context is not current. I try using setContext() on either the GLJPanel or the my version of JoglAWTCanvas, but I don't know what to hook up to that, since the context is null for either, and not setting it spits this out:

Exception in thread "AWT-EventQueue-0" com.jogamp.opengl.GLException: Caught GLException: AWT-EventQueue-0: This context is not current. Current context: WindowsWGLContext [Version 3.3 (Compat profile, arb, compat[ES2, ES3], FBO, hardware) - 3.3.0 [GL 3.3.0, vendor 0.0.0 (n/a)], options 0x2c03, this 0x1d4d56f1, handle 0x10002, isShared false, jogamp.opengl.gl4.GL4bcImpl@4af1ad73, etc etc.

I guess the question now is, how to set the context, or where does it get created?

Thanks.

The context should be current when the method currently called is directly or indirectly called within a callback of a GLEventListener. Sorry, JoglAWTCanvas is a misleading name. I should move JoglAWTCanvas into JoglNewtAwtCanvas and resurrect the old JoglAWTCanvas, etc... in order to obtain something similar to what is possible with JogAmp's Ardor3D Continuation.

Ah, I see. Well, I've been researching online and came across something on GLWindow and it says that a GLContext is automatically created when GLWindow is created, and I'm sure that it's the same for GLJPanel. But when I do tracing, the context is null for both when I do, and I can find no way to set it using setContext() so I can do makeCurrent().

Edit: I was able to break through using GLContext.getCurrentGL().getContext(). I had to use LibGDX Gdx.app.postRunnable(), but I've read somewhere that there's Threading.invokeOnOpenGLThread(), but I can't seem to load it from what's available on this libgdx + jogamp backend checkout.

Now that the context is set, the LibGDX processes are kicking in and passes through to JOGL, which brings me to the next error. When creating a SpriteBatch it errors out with this:

com.jogamp.opengl.GLException: AWT-EventQueue-0: No OpenGL context current on this thread
        at com.jogamp.opengl.GLContext.getCurrentGL(GLContext.java:509)
        at com.badlogic.gdx.backends.jogamp.JoglGL20.glCreateShader(JoglGL20.java:173)
        at com.badlogic.gdx.graphics.glutils.ShaderProgram.loadShader(ShaderProgram.java:194)
        at com.badlogic.gdx.graphics.glutils.ShaderProgram.compileShaders(ShaderProgram.java:173)
        at com.badlogic.gdx.graphics.glutils.ShaderProgram.<init>(ShaderProgram.java:156)
        at com.badlogic.gdx.graphics.g2d.SpriteBatch.createDefaultShader(SpriteBatch.java:156)

Wrapping the creation process of my renderer in this part with another postRunnable gets it to pass, but it also makes the rest of the startup process out of sync, throwing NPEs, unless I also pass these parts as a postRunnable to the OpenGL thread, which is not how I want to do it, of course.

I'm puzzled, I'm in the OpenGL context of LibGDX (else I'd have gotten this error without using the jogamp backend), so why isn't this recognized in the jogamp backend?

There is no OpenGL context of LibGDX, LibGDX relies on several Java bindings for the OpenGL and OpenGL-ES APIs to manipulate the OpenGL context, it wraps those bindings into a middle level abstraction. I understand that you want to make it work. If you're not yet able to confirm it, check whether GLJPanel really works very well with SwingNode for your use case. If so, check whether JoglSwingCanvas (JogAmp's Ardor3D Continuation) works correctly with SwingNode and if it's the case, porting JoglSwingCanvas to LibGDX will be worth it and I'll do so myself. If you try to solve too many problems at once, you will fail. Make a plain Swing canvas work first and then make it work with JavaFX / OpenJFX, it will help to find the culprit.

I can resurrect the old JoglAWTCanvas and move the current one into JoglNewtAwtCanvas in a few days, this is the least I can do to help you. When it's done, then I'll have you to test them a bit without JavaFX as a first step. After that, I can implement JoglSwingCanvas. Is it ok for you?

gouessej wrote

There is no OpenGL context of LibGDX, LibGDX relies on several Java bindings for the OpenGL and OpenGL-ES APIs to manipulate the OpenGL context, it wraps those bindings into a middle level abstraction. I understand that you want to make it work. If you're not yet able to confirm it, check whether GLJPanel really works very well with SwingNode for your use case. If so, check whether JoglSwingCanvas (JogAmp's Ardor3D Continuation) works correctly with SwingNode and if it's the case, porting JoglSwingCanvas to LibGDX will be worth it and I'll do so myself. If you try to solve too many problems at once, you will fail. Make a plain Swing canvas work first and then make it work with JavaFX / OpenJFX, it will help to find the culprit.

Thanks for the explanation. I am new to game development and OpenGL, and I admit that I'm still a bit out of my element at this point.

I think I now understand what you've wanted me to do all along, which is to launch my app within a JOGL window that hosts a GLJPanel (?) Sorry, I admit that I had tunnel-vision on getting the JavaFX aspect to work. I did get my app to work as a JOGLApplication in a GLWindow, so I'm guessing this will turn out well enough on GLJPanel. I'll get to it.

gouessej wrote

I can resurrect the old JoglAWTCanvas and move the current one into JoglNewtAwtCanvas in a few days, this is the least I can do to help you. When it's done, then I'll have you to test them a bit without JavaFX as a first step. After that, I can implement JoglSwingCanvas. Is it ok for you?

This is more than I can ask for, thank you. Sounds good to me :)

Edit #1:

Well that was painless. Running my app using JoglAWTCanvas, putting the NewtCanvasAWT inside a GLJPanel works, and FPS didn't take a hit (my app isn't effects heavy yet).

Putting my app into GLJPanel and adding it to a JDialog window, also had no problems.

I don't think I'll be able to really test SwingNode as well as you suggested, since it's a JavaFX component, which is the heart of the matter. But doing these latest things taught me a couple of new things about reordering stuff so I need not do things like in my previous posts (setting size etc. And I even don't need to set GLContext anymore).

Encouraged by this, I made a JavaFX stage, put in a SwingNode on an AnchorPane layout, and set the SwingNode contents to what worked in run # 1 (JoglAWTCanvas + NewtCanvasAWT + GLJPanel). No errors, and the LibGDX components gets created fine. The LibGDX rendering process loops just fine as well. But on the SwingNode, it only shows a black screen, which resizes correctly, but that's it.

adam_law wrote

Well that was painless. Running my app using JoglAWTCanvas, putting the NewtCanvasAWT inside a GLJPanel works, and FPS didn't take a hit (my app isn't effects heavy yet).

The speed of GLJPanel depends on the hardware as it uses FBO (mandatory?) and GLSL (optional) under the hood.

Anyway, I think that JoglSwingCanvas will solve your problem. I will start moving and adding some stuff into LibGDX in about ten hours.

gouessej wrote

The speed of GLJPanel depends on the hardware as it uses FBO (mandatory?) and GLSL (optional) under the hood.

Anyway, I think that JoglSwingCanvas will solve your problem. I will start moving and adding some stuff into LibGDX in about ten hours.

Sounds great. I can't wait to test it out. Thank you :)

You're welcome. I need some time to implement these stuffs correctly.

I'm currently committing a few changes, step by step. You will have to use JoglSwingApplication, which uses JoglSwingGraphics, which uses GLJPanel. I do my best to provide a GLJPanel without any AWT canvas and without NewtCanvasAWT.

At first, I'm currently moving lots of methods from JoglGraphics to JoglGraphicsBase and I'm implementing a few missing features (discontinuous rendering, frame identifier, ...). Then, I will create several classes extending JoglGraphicsBase and I'd like to avoid keeping tons of AWT dependencies in all those subclasses so that Xerxes and others can (maybe?) run our backend under Android.

I would appreciate that some people here give a try to our JogAmp LibGDX backend in order to check whether this commit causes some regressions:
https://github.com/gouessej/libgdx/commit/69cb08144bfde491ba66ac240288a8b276e7553d

gouessej wrote

I would appreciate that some people here give a try to our JogAmp LibGDX backend in order to check whether this commit causes some regressions:
https://github.com/gouessej/libgdx/commit/69cb08144bfde491ba66ac240288a8b276e7553d

...You're welcome. I need some time to implement these stuffs correctly.

I'm currently committing a few changes, step by step. You will have to use JoglSwingApplication, which uses JoglSwingGraphics, which uses GLJPanel. I do my best to provide a GLJPanel without any AWT canvas and without NewtCanvasAWT.

At first, I'm currently moving lots of methods from JoglGraphics to JoglGraphicsBase and I'm implementing a few missing features (discontinuous rendering, frame identifier, ...). Then, I will create several classes extending JoglGraphicsBase and I'd like to avoid keeping tons of AWT dependencies in all those subclasses so that Xerxes and others can (maybe?) run our backend under Android.

No problem. I can wait :) I wish I had some existing projects that uses the backend, but this is my 1st project of this type :( sorry.

adam_law wrote

No problem. I can wait :) I wish I had some existing projects that uses the backend, but this is my 1st project of this type :( sorry.

I'll test with the provided examples. I hope that the changes will be really useful for you because I'm sure that it's already possible to use JOGL with JavaFX/OpenJFX directly without a scenegraph or an engine and it's doable both with JogAmp's Ardor3D Continuation and JMonkeyEngine. Are you really forced to use LibGDX?

gouessej wrote

adam_law wrote

No problem. I can wait :) I wish I had some existing projects that uses the backend, but this is my 1st project of this type :( sorry.

I'll test with the provided examples. I hope that the changes will be really useful for you because I'm sure that it's already possible to use JOGL with JavaFX/OpenJFX directly without a scenegraph or an engine and it's doable both with JogAmp's Ardor3D Continuation and JMonkeyEngine. Are you really forced to use LibGDX?

I think this will be immensely helpful, not just for my LibGDX use case, but for others as well. We've looked and saw that there is no viable option right now to easily fuse JavaFX with any of the OpenGL-based frameworks, apart from the PoC projects done by Aqd, and Spasi. I believe you when you say that it's possible for JOGL to interface directly with JavaFX, but that detail isn't seemingly easy to find, and we've looked over the course of a year :))

Yeah, there's too much momentum on this project of ours where we've done about a year and half worth of work on a JavaFX based UI for desktop work, and a LibGDX-based rendering system for the app, not to mention a Nashorn-based scripting system, so we're kind of heavily invested in JavaFX 8+.

Both halves of our team were working separately at different parts of the world, and "made a mistake" forecasting that Java 8 would provide a means to join our work, at the very least through SwingNode. Hoo boy...

Sorry if I made you do a lot of work XD I can't thank you enough.

Edit: oh, forgot to mention is, our current endeavor is mostly 2D, which might explain why we chose LibGDX in the first place, can't say for sure, I'm on the UI team :))

I advise you to read my comments here:
https://jogamp.org/bugzilla/show_bug.cgi?id=607

JavaFX/OpenJFX isn't currently designed to work correctly with anything except itself. Maybe you'll get something working but it will have some limitations.

Don't be sorry but I'm not very satisfied with the JogAmp LibGDX backend, it tries to provide the same features than other desktop LibGDX backends but they are designed with the limitations of other frameworks in mind.

I just hope that JoglSwingApplication and JoglSwingGraphics will work with SwingNode.

I actually read that as part of my search that led me here. It drove point home regarding having few viable options for integrating with JavaFX. Of the strategies mentioned there, it seemed SwingNode was the "easiest" solution, albeit, with a likely performance cost.

Since our application, in desktop mode, isn't one that requires heavy effects and snappy performance at all times, the solution was the one we were looking for. In this mode, it functions more to administer or design, than actual play, which is why we wanted to leverage JavaFX. Once the simulation commences, the JavaFX components take a backseat, and we can then put the rendering system within something like a JoglFrame or as a JoglApplication, the rest of the way.

I hope that it works as well XD Even if it doesn't perform as well as if it were launch "natively" it'd be godsent if all aspects display correctly. On the PoC projects, certain stuff don't show, such as FBO-based lighting and shadow, to name one.

May I ask, based on what I've seen in the backend source, and while working on it, I noticed that these components inherit, or supply the part of the Gdx context, such as input, IO, audio etc. Does this mean that we don't have to use an intermediate input scheme to capture JavaFX events and translate it down to Gdx? On the Aqd project, and it's parent project, there was a class called XpefInput that did this translation. It shouldn't be a problem translating this to capture from SwingNode, but I was just curious if this translation need be made, or not.

Thanks :)

Actually, as I (still) can't use JavaFX/OpenJFX, if there is something left to do to make it work, it will be up to you ;)

gouessej wrote

Actually, as I (still) can't use JavaFX/OpenJFX, if there is something left to do to make it work, it will be up to you ;)

:)) That's more than fair enough.

I have committed numerous changes but I still have to rename some classes and to implement JoglSwingGraphics & JoglSwingApplication. The AWT (without NEWT) classes are still a bit broken, it's a work in progress. I just wanted to commit and push something before falling asleep. Best regards.

I have committed the rest of the source code. I have tested nothing yet, I need to have a rest. You can look at the source code if you want but if you run some examples, expect some instability.

I will try to find some time tomorrow to give it a try. I'm very skeptical about this backend, I don't see a lot of developers asking for help or new features. Either it works very well or it is used only by a very few developers. I tend to think that the second option is closer to the reality.

Thanks gouessej :)

Personally, I think it's just that most people are not aware of it. Up to the point where you pointed out that LWJGL was not your work, but a rival's, I thought contributors were all working on the one backend, and this thought process led me here, after following the online trail of potential solutions.

When I first ran our app as JoglApplication, I was surprised; surprised that there were now 2 branches to run a desktop app , and both work as well, on the surface, as the other. There were some slight visual differences, and I must admit that running under JOGL, things look crisper, apart from the startup "hiccup" I mentioned early on, I feel I'd prefer to use the Jogl backend.

Most of the literature on the LibGDX wiki, and code samples all launch from an LWGL-based container. Perhaps getting someone on their side to append a header or footer that links to the JOGAMP classes, or, better yet, alternate samples using the JOGAMP backend, would see people using it more.

Not wanting to be ignorant as I was when I first came here, I read up on some of the history between your rival implementations. JOGL seems to have an unbroken line of development; both JOGL and LWJGL have impressive histories of usage, but LWJGL seems to have broken off their design trajectory going into version 3, citing difficulties in implementing future plans on the previous code-base. With such a wealth of info, someone choosing between backends would have compelling reason to choose, instead of opting for what's prominent in the documentation/wiki.

Idk, it may just be me, but I think most LibGDX (and other framework users), implement some sort of level editor, or simulator, on the desktop. From what I can tell, most have to do it in Swing, or design a UI from the ground up, like Spine (according to their docs), in order to integrate a created app. Swing has served me well over the years, but since I've started using JavaFX 2, now 8, it is now my preferred UI toolkit for Java; it's just so far ahead.

I think the reason why you, or the other experts in the field I've talked to, don't see this as anything significant in the big picture, is because you all have a wealth of options and knowledge that make JavaFX insignificant :)) I mean, from all the conversations I've had, the most common line I got back was "I haven't used JavaFX yet" or "I've used it, but I already have a UI toolkit I made myself." The rest of us humans either aren't us prolific, or are constrained by time and minimal resources. Leveraging what's available is the norm for people like me, and things like what you're doing here right now, is a huge boon :D

For this reason, if this succeeds, I can imagine an uptick in demand for the JOGAMP backend, once LibGDX people realize, as we have, what can be done with a JavaFX UI and an OpenGL display. I would think this will hold true for other frameworks with JOGAMP support, not just LibGDX, if this were made part of their set of options. As far as I can tell, your work on GLJPanel is the only embeddable component that SwingNode can carry to display OpenGL. Barring Oracle bridging the gap themselves, it looks to be the best option avaliable.

Anyway, you have the gratitude of at least 20 people that make up my team. That should count for something, I hope