JOGL in JavaFX

Since the JavaFX forum seems a bit dead, I hope someone will at least read this post.
Especially I have a question for gouessej:

  • is it possible to use JOGL with JavaFX ?
  • if not, is it planned ?

I’ve searched without success whether it is possible to integrate a JOGL container into JavaFX.
It seems impossible.
There is the JFXPanel, but I would prefer going full Swing or full JavaFX, but not mixing the two.

GUIs made with JavaFX look just gorgeous, and styling with CSS is a lot of fun.
Guess I’ll have to fiddle with Nimbus in the meantime.

Yes, it is already working with JOGL 1.1.1a and JavaFX 1.3 but it doesn’t work anymore with JavaFX 2 (even though JavaFX uses a “private” version of JOGL).

JOGL is a community project independent of Oracle. There is no plan yet.

JFXPanel allows to embed JavaFX components into a Swing GUI, I’m not sure it is really suitable.

We need a lower level access to support JavaFX with JOGL, we could find a solution by looking at OpenJFX but if JavaFX uses Direct3D under Windows, we won’t be able to use JOGL. We had the same problem with Java3D 1.5, I solved it in Java3D 1.6 pre by dropping the Direct3D backend.

Thanks or your quick reply!
Do you read every post on these forums? LOL :o

[quote]Yes, it is already working with JOGL 1.1.1a and JavaFX 1.3 but it doesn’t work anymore with JavaFX 2 (even though JavaFX uses a “private” version of JOGL).
[/quote]
That’s what I feared.
I’m with JOGL 2, and was planning to use JavaFX 2, since 1.3 is dead.

[quote]JFXPanel allows to embed JavaFX components into a Swing GUI, I’m not sure it is really suitable.
[/quote]
I was thinking about putting JOGL in Swing, then do the rest of the app’s GUI in JFXPanels. But from my little trivial tests, performances are noticeably degraded when embedding JavaFX in Swing, and I find that solution ugly design-wise; I might be masturbating though…

[quote]We need a lower level access to support JavaFX with JOGL, we could fund a solution by looking at OpenJFX but if JavaFX uses Direct3D under Windows, we won’t be able to use JOGL. We had the same problem with Java3D 1.5, I solved it in Java3D 1.6 pre by dropping the Direct3D backend.
[/quote]
Since JavaFX is the new GUI in the Java world, there will be a point where JOGL will have to be ported. Swing will be available for the next 10 years or so I guess (an eternity), but still…

If JavaFX doesn’t enable to deactivate its Direct3D backend, using it with JOGL will be totally impossible because there would be a conflict at driver level. I hope you really understand that. I’m not against JavaFX but I refuse promising the implementation of a feature when I know we won’t be able to achieve it. Feel free to contribute, maybe write a request for enhancement, put it into our bug tracker.

You know I keep watch over the world wide web, especially the surface web and a part of the deep web.

[quote]I hope you really understand that.
[/quote]
Yes I do. I’m not blaming anyone :slight_smile:
I understand the technical difficulties. I just think it would be a waste if, in time, Oracle did not do the necessary to allow JOGL (and similar) to be ported to JavaFX, especially as it is one of the rare ways to integrate OpenGL in a GUI in Java. I even think Sun/Oracle should have already provided their own way to do it natively in Java, but this is another debate.

[quote]Feel free to contribute, maybe write a request for enhancement, put it into our bug tracker
[/quote]
Good idea, I’ll do it.

[quote]especially the surface web and a part of the deep web
[/quote]
So is javagaming.org part of the surface or underworld ?
I’d like to know where I stand :wink:

NEWT (the native windowing toolkit of JOGL) can probably be used with JavaFX.

Java-Gaming.org is indexed by search engines, it is obviously in the surface web.

[quote]NEWT (the native windowing toolkit of JOGL) can probably be used with JavaFX.
[/quote]
I had a look at it before starting this thread.
It doesn’t provide a JavaFX container.

I don’t see why it would work where AWT and Swing fail… ?
Did I miss something ?

I have just posted a question about JavaFX and interoperability with Java bindings for the OpenGL API on the main mailing list of OpenJFX developers.

We have the full control on NEWT as it doesn’t depend on AWT. If there is a way of using the OpenGL backend of Prism under Windows, we will be able to implement some interoperability between JavaFX and JOGL, that is a way of using JavaFX components inside a NEWT container (GLWindow), a way of using NEWT components inside a JavaFX container and some ways of interacting with Prism rendering to inject JOGL calls directly in the painting of JavaFX components (and vice versa).

[quote]Feel free to contribute, maybe write a request for enhancement, put it into our bug tracker
[/quote]
I submitted the feature request
https://jogamp.org/bugzilla/show_bug.cgi?id=607

[quote]I have just posted a question about JavaFX and interoperability with Java bindings for the OpenGL API on the main mailing list of OpenJFX developers.

We have the full control on NEWT as it doesn’t depend on AWT. If there is a way of using the OpenGL backend of Prism under Windows, we will be able to implement some interoperability between JavaFX and JOGL, that is a way of using JavaFX components inside a NEWT container (GLWindow), a way of using NEWT components inside a JavaFX container and some ways of interacting with Prism rendering to inject JOGL calls directly in the painting of JavaFX components (and vice versa).
[/quote]
This would be very nice.
I hope there is some possibilities, and also some interest.

Hi

I have studied that RFE for several hours, it won’t be possible or it will require a lot of time, I will explain it in details in your bug report.

Replied on the bug report
https://jogamp.org/bugzilla/show_bug.cgi?id=607#c2

Note that the JavaFX devs have mentioned themselves that even though it is possible to reach some low level stuff in JavaFX now when you bypass the API, as soon as Java goes “modular” through Jigsaw (whenever that is going to be), it will become impossible to still do that as it will all be completely hidden away. I’ve seen some discussions on the OTN forums about the subject of hooking Java3D or JOGL into JavaFX, it looks like Oracle wants to keep it nice and contained.

Do you have some links about that??

There are 2 new additions to JavaFX in 2.2 (http://fxexperience.com/2012/08/javafx-2-2-is-here-and-javafx-8-0-is-on-its-way/) that caught my eye, regarding OpenGL support:

  • a canvas node
  • writable images

Can’t these help in porting JOGL to JavaFX ?

No, it can’t, the canvas node is helpful for guys who want to port HTML5 applications to JavaFX. I will write a request for enhancement about our problem in about ten hours still on Kenai but I’m not sure it is the right place to do so.

Sorry, I missed your question :frowning: Let me see if I can dig it up.

EDIT:

hmm well this is one: https://forums.oracle.com/forums/thread.jspa?messageID=10470743

That is not the one I’m mainly referring too though, but of course the OTN forum’s search is horrible and I’m not finding the relevant thread. If I come across it again I’ll certainly post it :frowning:

Hi, I just wanted to share my experiences on this topic:

Short version: on Mac OS X it can be done, although hacky.

At work we use JavaFX 2 on MacOSX for an editor / content management system with some fancy 3D graphic
eyecandy.
We needed to integrate an existing 3D engine (standalone app) and used IOSurface to show the result in JavaFX.
On Mac OS X it’s rather simple to write a custom node an overwrite the _impl_createNGNode (or something).
Until 2.2 you even got a graphics object in the render call that can be cast into a jogl GL interface to access OpenGL directly.
You needed to take care about setting / saving some render states but it works pretty nice. After one beta update in 2.2 the
GLESPipeline changed and did not allow full access to OpenGL
functionality anymore. But you can still simple call opengl commands since the NGNode.render() function is called in the OpenGL render
context thread.
We had to use a outdated openGL java binding because unfortunatly neither JOGL nor LWJGL could be used (JOGL needs some
kind of window handle even though you just want to call some openGL commands, and LWJGL crashes because some static
initializer starts up AWT with makes JavaFX2 crash). But it still works very nice.

I suppose we will have to patch our hacky solution when the internal structure changes. Ideally they would implement a
factory pattern that creates the NGRender nodes corresponding to the ui data models.

There are also hints in the class files that an JavaFX 2 OpenGL implementation for Windows already exists, some strings starting
with WGLXXX, compared to the mac implementation starting with CGLXXX. But those files aren’t released. I’ve fiddled
a bit with an own “class GLPipeline extends GraphicsPipeline” for windows, and think it can be done with about 10 classes,
but I’m not sure about legal implications till it’s open sourced.

IMO it’s very important that JavaFX 2 will allow low level access to 3D hardware. Many cool effects like complex
3D objects, raytracing, screen space ambient occlusion, shadow mapping, particles etc are only possible with
direct access to hardware.
I really hope that JavaFX 2 will indeed become open source. If they release the prism part it wouldn’t be
much trouble to add an optional OpenGL pipeline for Windows. This would allow writing platform independent OpenGL
nodes.

Instead of the Canvas node, they should add a “OpenGL” node where you pass an “RenderNode” interface where
you can call openGL commands, with a predefined render state. A kind of “use at your own risk” node would be fine
with me =)

Another good feature for JavaFX 2 would be a “SharedSurface” node via DirectX shared surface / mac os x IOSurface,
so you can integrate framebuffers from other processes. This would help integrate any existing rendering solution.

Hi

I’m not sure you’re right about JOGL 2.0 (I already used an external context without any window handle) and anyway, there should be a way of getting this window handle. You’re wrong about Windows, we have no way to force JavaFX to use OpenGL instead of Direct3D. Your suggestions work under Mac, they could be ported to GNU Linux but the main problem is still under Microsoft Windows. I’m glad to learn some things about your findings and I hope you will share them. I’m a bit skeptical because I was in a similar situation some years ago, a guy said he had ported Ardor3D to JOGL 2.0 and that he would share his source code. Do you know what happened at the end? He never shared it and I had to port this engine to JOGL 2.0 by myself.

Edit.: I have no access to Prism source code and you talk about this class: com.sun.javafx.sg.prism.NGNode
Edit.2: The source code of Quantum is not yet open source.
Edit.3: Maybe you can use GLContext.getCurrentGL(), GLDrawableFactory.createExternalGLContext() or GLDrawableFactory.createExternalGLDrawable().
Edit.4: You can get the window handle with a GLDrawable instance but it is useless as you can already use my suggestion to create an external GLDrawable, call getGL() on it and use your OpenGL commands.
Edit.5: I’m investigating, you can do some reverse engineering on JavaFX by downloading the latest version of Oracle JDK 1.7 update 6 and looking at jre/lib/jfxrt.jar
Edit.6: I use JD-GUI to decompile JavaFX. NGNode is abstract, I don’t find its child classes.
Edit.7: NGNode has lots of child classes: NGCanvas, NGGroup (NGRegion, NGWebView), NGImageView, NGMediaView, NGShape (NGArc, NGCircle, NGCubicCurve, …). The hack should be more useful in NGCanvas.
Edit.8: Quantum enables AWT headless mode, keep it in mind, avoid calling AWT methods that do not work in this mode.
Edit.9: Dejay’s suggestion is not trivial to implement with the latest version of JavaFX 2.2 because it is impossible to instantiate NGNode.
Edit.10: You can use com.sun.prism.es2.ES2Pipeline to get the (public static) GLFactory or directly GLFactory.getFactory(). If you find which class use this factory to create the GLDrawable, then you can do whatever you want :wink:
Edit.11: Oracle has probably dropped JOGL. All OpenGL calls seem to be done in native code. The GLDrawable contains the native window handle (see getNativeWindow()). Creating an external drawable and using it at the appropriate time seems to be the only way to support JOGL 2.0 in JavaFX.
Edit.12: You can get the graphics pipeline by calling com.sun.prism.GraphicsPipeline.getPipeline().

JFXPanel could be a nice source of inspiration to write a NEWT component embedding a JavaFX scene.

The JOGL 2.0 rendering should be done in classes overriding Prism NG* classes. These classes should perform the JOGL 2.0 rendering in doRender(Graphics) or rather in renderContent(Graphics) (if you want to get the proper transforms).

impl_createPGNode() and impl_getPGNode() in javafx.scene.Node are deprecated, the creation is done in Quantum most of the time but I have found no way of setting a custom toolkit and Toolkit.getToolkit() can’t be overridden of course. Dejay is right, the key is javafx.scene.Node.impl_createPGNode(). It would be easier and safer if we could rely on a public non deprecated method. Overriding existing nodes so that they use our peers instead of Prism NG* classes should work with the external contexts and drawables.

I will try to implement a blueprint tomorrow if I’m really motivated and not too much tired.

Thanks again for looking into this.

I can’t stop wondering why Oracle/the JavaFX team seem to ignore JOGL.
Showcasing OpenGL-powered 3d apps working in tandem with pretty JavaFX GUIs would be a major selling point for them.