Abstract OpenGL layer to allow for JOGL or LWJGL backends

[elfprince13]

I'm currently testing out a project in LWJGL and was considering using something like the CSSBox library to ease the burden on UI development - except that it's rendering pipeline depends on Java2D and AWT!

I'd love to be able to just create a dummy AWT Container subclass that redirects the rendering to my OpenGL context via glg2d, however right now glg2d is dependent on JOGL specifically. It seems like it should mostly be boilerplate changes (rather than logic) to be able to support both of these. All seems as if maintaining both of these rendering paths within the official repo would more easily keep feature parity between them (as opposed to forking). Any thoughts?

[brandonborkholder]

Thank you for the interest, but I'm not interested in supporting two different OpenGL wrappers. I would much prefer to see the JOGL interfaces wrap the LWJGL implementation - but i don't know enough about LWJGL to know if that would be reasonable.

[elfprince13]

As I understand it, the primary difference is that lwjgl uses nio buffers instead of arrays, and has a static interface (where JOGL has a GL object that must be instantiated).

How modularized is the JOGL code in your current implementation? Is it pretty much all in one set of classes that are utilized by the outside? Or is it pretty well interspersed? If the former, than I may well try to make some of the changes myself and see how it turns out.

[brandonborkholder]

There are references to JOGL throughout the code. However, there are only a few classes that actually make calls into the JOGL library. Most of that is under org.jogamp.glg2d.impl.gl2. You can ignore the shader package as that's not used yet. JOGL also uses NIO buffers and I use them in my code. If LWJGL tries to stay close to the actual OpenGL calls, the translation should not be that difficult.

If you do run into issues where you're not sure what I'm doing, reply to this thread and I'll be happy to help.

[elfprince13]

I have hacked together some things that seem to work in the single use case I've tested them on. https://github.com/elfprince13/glg2d

Had to do kind of a hatchet job, because the LWJGL rendering model is much less sophisticated than the JOGL one, so the assumption is generally that there's only a single thread.

I'll probably update and test it more thoroughly down the road, but the parent project for which I'm working on this has some more pressing issues that I've switched over to, so it might be a while and I figured I'd post the code in the meantime in case someone else can make use of it.

[ghost]

Hi

I don't want to offend you @elfprince13 but you knew you were running the risk of a refusal as this project is a part of our ecosystem, the package name clearly suggests it ("org.jogamp.glg2d", JOGL is one of the APIs managed by the JogAmp community). Brandon's first suggestion is reasonable and partially doable as long as you stay far from the widget toolkits but your first attempt seems to be easier to maintain anyway. I'm really shocked by what you wrote about JOGL which has used NIO buffers since it became publicly available in Java 1.4.

@brandonborkholder Why not closing this issue? He could still post updates about his port, of course you're free to help him but whether it works or not is none of "our" concerns, isn't it? Keep up the good work :)

[elfprince13]

@goussej I don't really understand the purpose of your comment. I said nothing to indicate that I was upset by Brandon's refusal (and for that matter I haven't said anything at all on this subject for 1/3 of a year at this point), and afaict, this is not an official JOGL or jogamp library, so it strikes me as odd that you are so proprietary towards someone else's work. As for the NIO buffers...I don't want to offend, but I can't be held responsible for the state of library documentation as it appears when I use Google.

[ghost]

@elfprince13 The documentation of the latest version of JOGL is here (and this is what Google suggests me when I enter "JOGL API documentation"): http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/

GL2 is only present in JOGL 2.x, you should have quickly noticed that you were looking for the wrong documentation, it has nothing to do with Google.

I don't appreciate people who disparage JogAmp APIs and you should have made some more verifications before claiming that JOGL doesn't support NIO buffers (which was already wrong in 2006). I don't want this thread to be used to promote the main competitor of JogAmp and to make wrong claims about what it supports or not. I'm not "proprietary" towards anybody else's work but who are you to tell us which projects are part of the JogAmp APIs whereas you don't even know JOGL? The package name "org.jogamp.glg2d" hasn't been chosen by chance and as far as I know, as your port doesn't keep the JOGL code, please could you rename the package to avoid any confusion (JogAmp has nothing to do with the library you use) and to help the future maintainers to merge what you did with the trunk if this project doesn't become a part of JogAmp APIs?

I'm responsible for engine support. If there is no plan of "fixing" this "bug", it should be closed, shouldn't it? I just want to see the remaining bugs, not the refused requests for enhancement (the use of the word "enhancement" is highly questionable to me in this context).

[brandonborkholder]

I'm closing this issue since it hadn't been active for 4 months.

@gouessej I clearly told @elfprince13 that I was not integrating his work and I kept this thread open to provide him assistance if needed it, on his own fork. This thread isn't to discuss JOGL's use of NIO or documentation.