I don’t have a lot of time to work on it. Some help would be welcome. Decompiling JavaFX is not difficult with JD-GUI (I will give some money to the creator of this nice tool).
Keep in mind that Oracle gave up JOGL and now it uses only native OpenGL calls, no real binding. I’m not very motivated to make an effort on something that might be quickly broken if Oracle modifies its APIs.
Hello Julien,
thank you for your tips in edit 3, I’ll check it out. I’m a bit embarrassed but I got a little lost with the NEWT
classes for window handling. They are also in different packages. I’m always so damn impatient =)
I have also made a post in the oracle forum, I just hope I’m not waking sleeping dogs but get a good response 
https://forums.oracle.com/forums/thread.jspa?threadID=2434547&tstart=0
Hopefully they’ll make prism open source soon. I totally understand your hesitation about the evolving JavaFX code
structure. I can also totally understand the JavaFX team desire to encapsulate the rendering pipeline to avoid breaking
applications for updates. I still think it’s very important to be able to do stuff like this.
[quote]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.
[/quote]
I used NGRegion which has a public constructor and doesn’t do much, but I’m hoping when they remove the impl methods they will
provide a better mechanism like a factory pattern where you can register rendering controllers for new nodes.
Probably NGCanvas has a lot of stuff in it already for the deferring of the canvas draw calls.
What I’ve tried is implementing a “JOGLPipeline” that only seems to need 7 classes that make up the render pipeline. Basically
an abstraction of shaders, vertex buffers and some predefined shaders to render shapes with compositing etc. The design of
the prism renderer is pretty nice IMO.
I’ve pasted my pathetic code for your entertainment: https://gist.github.com/3564076
public class JOGLPipeline extends GraphicsPipeline
public class JOGLResourceFactory extends BaseShaderFactory
public class JOGLPresentable implements Presentable, GraphicsResource
public class JOGLContext extends BaseShaderContext
public class JOGLShader implements Shader
public class JOGLVertexBuffer extends VertexBuffer
public class JOGLGraphics extends BaseShaderGraphics
And a class “com.sun.prism.jogl.JOGLPipeline extends org.dejay.prism.opengl.JOGLPipeline”.
This can be injected into PrismSettings (it’s instantiated with string concatenation and getClassForName)
PrismSettings.verbose = true;
PrismSettings.tryOrder = new String[] { “jogl” };
Application.launch(args);
I’ve only implemented some log traces and rendered an empty scene to find out what’s happening.
I’m not sure how to attach a jogl GLWindow to the view created by JavaFX glass. Atm I tried:
window = NewtFactory.createWindow(view.getNativeView(), screen, new GLCapabilities(GLProfile.getDefault()));
glWindow = GLWindow.create(window);
Log output:
Prism pipeline name = com.sun.prism.jogl.JOGLPipeline
(X) Got class = class com.sun.prism.jogl.JOGLPipeline
Initialized prism pipeline: com.sun.prism.jogl.JOGLPipeline
INFO: org.dejay.prism.opengl.JOGLPipeline init -
INFO: org.dejay.prism.opengl.JOGLPipeline getDefaultResourceFactory screens: 2
INFO: org.dejay.prism.opengl.JOGLResourceFactory createVertexBuffer
RESIZE: 3115294780147 w: 184 h: 162
INFO: org.dejay.prism.opengl.JOGLPipeline getDefaultResourceFactory screens: 2
INFO: org.dejay.prism.opengl.JOGLResourceFactory createRenderingContext
INFO: org.dejay.prism.opengl.JOGLResourceFactory createPresentable view: com.sun.glass.ui.win.WinView@42f25b18
INFO: org.dejay.prism.opengl.JOGLPresentable <init> context: org.dejay.prism.opengl.JOGLContext@13417588 view.getNativeView: 526108
INFO: org.dejay.prism.opengl.JOGLPresentable <init> glWindow: NEWT-GLWindow[
Helper: GLAnimatorControl: null, GLEventListeners num 0 [],
Drawable: null,
Context: null,
Window: jogamp.newt.driver.windows.WindowsWindow[Config null
, NEWT-Screen[Windows_nil-10, idx 0, refCount 0, 0x0, null, NEWT-Display[Windows_nil-1, refCount 0, hasEDT true, edtRunning true, null]]
, ParentWindow null
, ParentWindowHandle 0x8071c (true)
, WindowHandle 0x0
, SurfaceHandle 0x0 (lockedExt window false, surface false)
, Pos 64/64 (auto true), size 128x128
, Visible false, focus false
, Undecorated true (true)
, AlwaysOnTop false, Fullscreen false
, WrappedWindow null
, ChildWindows 0, SurfaceUpdatedListeners num 0 [], WindowListeners num 1 [com.jogamp.newt.opengl.GLWindow$1@19a8cd8a, ], MouseListeners num 0 [], KeyListeners num 0 [], surfaceLock <194e2c2f, 5b36cea3>[count 0, qsz 0, owner <NULL>], windowLock <6b385e1d, 41aaf8e9>[count 0, qsz 0, owner <NULL>]]]
INFO: org.dejay.prism.opengl.JOGLPresentable createGraphics
INFO: org.dejay.prism.opengl.JOGLPresentable getContentX
INFO: org.dejay.prism.opengl.JOGLPresentable getContentY
INFO: org.dejay.prism.opengl.JOGLPresentable getContentWidth
INFO: org.dejay.prism.opengl.JOGLPresentable getContentHeight
INFO: org.dejay.prism.opengl.JOGLContext updateRenderTarget
INFO: org.dejay.prism.opengl.JOGLGraphics <init> GLGraphics
INFO: org.dejay.prism.opengl.JOGLGraphics clear Color: Color[r=1.0, g=1.0, b=1.0, a=1.0]
INFO: org.dejay.prism.opengl.JOGLResourceFactory createStockShader Solid_Color
INFO: org.dejay.prism.opengl.JOGLShader <init>
INFO: org.dejay.prism.opengl.JOGLShader enable
INFO: org.dejay.prism.opengl.JOGLContext updateShaderTransform
INFO: org.dejay.prism.opengl.JOGLContext updateCompositeMode
INFO: org.dejay.prism.opengl.JOGLPresentable prepare null
INFO: org.dejay.prism.opengl.JOGLPresentable present
RESIZE: 3117915405788 w: 184 h: 163
RESIZE: 3117917257574 w: 185 h: 163
RESIZE: 3117922342587 w: 186 h: 163
INFO: org.dejay.prism.opengl.JOGLPresentable recreateOnResize
INFO: org.dejay.prism.opengl.JOGLPresentable recreateOnResize
INFO: org.dejay.prism.opengl.JOGLPresentable createGraphics
INFO: org.dejay.prism.opengl.JOGLPresentable getContentX
INFO: org.dejay.prism.opengl.JOGLPresentable getContentY
INFO: org.dejay.prism.opengl.JOGLPresentable getContentWidth
INFO: org.dejay.prism.opengl.JOGLPresentable getContentHeight
INFO: org.dejay.prism.opengl.JOGLGraphics <init> GLGraphics
INFO: org.dejay.prism.opengl.JOGLGraphics reset
INFO: org.dejay.prism.opengl.JOGLGraphics clear Color: Color[r=1.0, g=1.0, b=1.0, a=1.0]
INFO: org.dejay.prism.opengl.JOGLShader isValid
INFO: org.dejay.prism.opengl.JOGLPresentable prepare null
INFO: org.dejay.prism.opengl.JOGLPresentable present
Hello Dejay
Good job 
Your source code is a nice way of beginning the implementation of JavaFX/JOGL interoperability but we still need to get a clear answer to these questions:
I’m not a big fan of Microsoft but if we can’t support Windows, all this is quite a waste of time.
I haven’t gotten any response of the devs to my post on the oracle forum yet.
[quote]- how to disable the Direct3D pipeline under Windows?
[/quote]
Theoretically with “-Dprism.order=es2” which sets “PrismSettings.tryOrder = new String[] { “es2” };”
This jira bug verifies that there exists an internal gles2 pipeline for windows:
http://javafx-jira.kenai.com/browse/RT-11208
Here is a very sad bug for you ;(
http://javafx-jira.kenai.com/browse/RT-17404
Apparently it was done to reduce memory footprint / startup time which makes sense,
since they only use a handful of methods to handle vertex buffers, textures, framebuffers etc.
But as long as you can bind JOGL to an existing gl context, it doesn’t matter I think. The internal
casting of Graphics to ES2Graphics is nice but the internal jogl wouldn’t be updated very often
anyway. IF and WHEN they release a gl es2 pipeline under windows.
I don’t know if you can use a OpenGL 3/4 context with a GLES context though.
Is it possible and realistic to do offscreen rendering with JOGL / LWJGL, then switch the result image to JavaFX ?
What approach would be better ?
(I don’t need state of the art graphics, I’m using the fixed pipeline. Rendering should be as fast as possible though)
I’ve seen terms such as pbuffers and FBOs… ??
Excuse my resurrection of this topic. I haven’t been around these parts in ages, but I have been following JavaFX development very closely…
See this thread
http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-May/007885.html
and this
http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-June/008423.html
Basically, there is strong interest from Oracle to expose something like a raw OpenGL surface in JavaFX. But it is still a ways off.
Excuse my resurrection of this topic. I haven’t been around these parts in ages, but I have been following JavaFX development very closely…
See this thread
http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-May/007885.html
and this
http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-June/008423.html
Basically, there is strong interest from Oracle to expose something like a raw OpenGL surface in JavaFX. But it is still a ways off.
Hi
I’ve just posted something about the most recent piece of information I obtained from Oracle about the use of native APIs (especially OpenGL) with JavaFX:
https://jogamp.org/bugzilla/show_bug.cgi?id=607#c13
I’ll start working on JavaFX when I have some time and when OpenJFX is bundled with OpenJDK (probably before March 2014). Keep in mind that I’m very busy (Ardor3D, NEWT Input API, …).
I think that Felipe answered to a lot of our questions about JogAmp OpenJFX / JavaFX interoperability in the document that I quoted in the bug report above.
Sorry to be unclear about the road map and contributions are welcome.
Hi
I’ve just posted something about the most recent piece of information I obtained from Oracle about the use of native APIs (especially OpenGL) with JavaFX:
https://jogamp.org/bugzilla/show_bug.cgi?id=607#c13
I’ll start working on JavaFX when I have some time and when OpenJFX is bundled with OpenJDK (probably before March 2014). Keep in mind that I’m very busy (Ardor3D, NEWT Input API, …).
I think that Felipe answered to a lot of our questions about JogAmp OpenJFX / JavaFX interoperability in the document that I quoted in the bug report above.
Sorry to be unclear about the road map and contributions are welcome.
Hi Julien, thanks for all your work on JOGL etc together with Sven and others.
Your idea to bring JOGL and JavaFX together would much be appreciated. Because, like you, I don’t want to throw away our good old computers just because they’re older but still work perfectly.
And JavaFX can be useful for new projects (not neccesarily as replacement for Swing), but its demand for newer GPUs is very hard, whilst JOGL runs nearly everyhwere.
“JavaFX 2 Certified System Configurations”
(And it’s not relaxed with JFX in Java 8…)
So, keep up the good work, and all the best!
Hi Julien, thanks for all your work on JOGL etc together with Sven and others.
Your idea to bring JOGL and JavaFX together would much be appreciated. Because, like you, I don’t want to throw away our good old computers just because they’re older but still work perfectly.
And JavaFX can be useful for new projects (not neccesarily as replacement for Swing), but its demand for newer GPUs is very hard, whilst JOGL runs nearly everyhwere.
“JavaFX 2 Certified System Configurations”
(And it’s not relaxed with JFX in Java 8…)
So, keep up the good work, and all the best!
Hi
You’re welcome. Sorry for the late reply, I was at the FOSDEM. I will implement GLJFXPanel (OpenJFX/JavaFX panel with JOGL support) for sure, this is the least I can do but I’m not sure that I will succeed in implementing a whole alternative pipeline for JavaFX which means that the native existing ES2 pipeline will have to be used (and shipped by yourself for Windows). If you target low end machines, just forget JavaFX. There is a need of a Java GUI widget toolkit working both in desktop and mobile environments but JOGL Graph UI has a very few components compared to Swing and it doesn’t support OpenGL(-ES) 1. I’ll need to find a real solution on the long term (which JavaFX isn’t despite its rich APIs).
Hi
You’re welcome. Sorry for the late reply, I was at the FOSDEM. I will implement GLJFXPanel (OpenJFX/JavaFX panel with JOGL support) for sure, this is the least I can do but I’m not sure that I will succeed in implementing a whole alternative pipeline for JavaFX which means that the native existing ES2 pipeline will have to be used (and shipped by yourself for Windows). If you target low end machines, just forget JavaFX. There is a need of a Java GUI widget toolkit working both in desktop and mobile environments but JOGL Graph UI has a very few components compared to Swing and it doesn’t support OpenGL(-ES) 1. I’ll need to find a real solution on the long term (which JavaFX isn’t despite its rich APIs).
The long term plan is to get JavaFX officially working on mobile platforms as well. Currently Oracle is targeting the desktops and embedded systems.
For example: http://stackoverflow.com/questions/20860931/is-it-possible-to-run-javafx-applications-on-iphone-android-win8-mobile
So it’s possible and I would even say it’s viable solution even for a long term plan.
The question rather is, does it help or is viable, to You, right now
The long term plan is to get JavaFX officially working on mobile platforms as well. Currently Oracle is targeting the desktops and embedded systems.
For example: http://stackoverflow.com/questions/20860931/is-it-possible-to-run-javafx-applications-on-iphone-android-win8-mobile
So it’s possible and I would even say it’s viable solution even for a long term plan.
The question rather is, does it help or is viable, to You, right now
xsvenson, have you ever worked on a professional application deployed on numerous customers and based on OpenJFX / JavaFX? Have you ever looked at the recommended configurations to run OpenJFX / JavaFX applications in good conditions?
http://docs.oracle.com/javafx/2/system_requirements_2-2-5/jfxpub-system_requirements_2-2-5.htm
http://www.oracle.com/technetwork/java/javafx/downloads/supportedconfigurations-1506746.html
Currently, there are lots of Android smartphones supporting OpenGL-ES 2 but their drivers often offer a better support of OpenGL-ES 1. The software renderer of OpenJFX / JavaFX is really slow. Even simple OpenJFX / JavaFX GUIs have an higher memory footprint than their Swing equivalents. As I explained in the bug report, Oracle already knows that some public APIs are missing to implement a viable interoperability without relying on private APIs that could be removed, there is no need to provide a semi-broken solution in JOGL. We are open to contributions, don’t worry and we listen to our community. Wouldn’t a GLJFXPanel be enough for your needs? If we provide enough instructions to help the developers to ship the native ES2 pipeline for Windows and enable it, there won’t be any problem of conflict at driver level with Direct3D. As I already said, you can still use GLJPanel + SwingNode + JFXPanel in the meantime. I have never denied that in my humble opinion JavaFX has some interesting features, a nice charting API, …
Maybe Preston agrees with me. My concern is that I don’t see JavaFX as a Swing replacement but I really want to provide some sort of interoperability between JOGL and OpenJFX / JavaFX. On my view, this feature is a “must have”. However, I don’t see a fully JOGL based pipeline for OpenJFX / JavaFX as an absolute necessity. What’s wrong with that? You can already tinker the software renderer based on Swing in order to use GLG2D when creating Graphics2D instances, it’s probably slower and less straightforward than a fully JOGL based pipeline but it’s better than nothing, isn’t it?
Sorry to contradict you but I don’t only implement features that I absolutely need or find viable otherwise I would have never contributed to Java3D, Xith3D, JMonkeyEngine, … but I won’t implement a feature that will get completely broken because of changes in private APIs. Please tell me clearly what you mean and what you expect. Right now I have a full time job and I’m responsible of engine support for the JogAmp Foundation on my spare time as a volunteer. There are only 24 hours a day :clue:
I haven’t done anything with JavaFX nor do I know anything about it really.
But I do know that there are some plans to get JavaFX to Android (how realistic the plans are, do not know) and I know that some ppl have it working on their phone, more or less.
My point wasn’t that ppl should use it now or whatever. It was rather “here, take a look, if You are interested”
xsvenson, have you ever worked on a professional application deployed on numerous customers and based on OpenJFX / JavaFX? Have you ever looked at the recommended configurations to run OpenJFX / JavaFX applications in good conditions?
http://docs.oracle.com/javafx/2/system_requirements_2-2-5/jfxpub-system_requirements_2-2-5.htm
http://www.oracle.com/technetwork/java/javafx/downloads/supportedconfigurations-1506746.html
Currently, there are lots of Android smartphones supporting OpenGL-ES 2 but their drivers often offer a better support of OpenGL-ES 1. The software renderer of OpenJFX / JavaFX is really slow. Even simple OpenJFX / JavaFX GUIs have an higher memory footprint than their Swing equivalents. As I explained in the bug report, Oracle already knows that some public APIs are missing to implement a viable interoperability without relying on private APIs that could be removed, there is no need to provide a semi-broken solution in JOGL. We are open to contributions, don’t worry and we listen to our community. Wouldn’t a GLJFXPanel be enough for your needs? If we provide enough instructions to help the developers to ship the native ES2 pipeline for Windows and enable it, there won’t be any problem of conflict at driver level with Direct3D. As I already said, you can still use GLJPanel + SwingNode + JFXPanel in the meantime. I have never denied that in my humble opinion JavaFX has some interesting features, a nice charting API, …
Maybe Preston agrees with me. My concern is that I don’t see JavaFX as a Swing replacement but I really want to provide some sort of interoperability between JOGL and OpenJFX / JavaFX. On my view, this feature is a “must have”. However, I don’t see a fully JOGL based pipeline for OpenJFX / JavaFX as an absolute necessity. What’s wrong with that? You can already tinker the software renderer based on Swing in order to use GLG2D when creating Graphics2D instances, it’s probably slower and less straightforward than a fully JOGL based pipeline but it’s better than nothing, isn’t it?
Sorry to contradict you but I don’t only implement features that I absolutely need or find viable otherwise I would have never contributed to Java3D, Xith3D, JMonkeyEngine, … but I won’t implement a feature that will get completely broken because of changes in private APIs. Please tell me clearly what you mean and what you expect. Right now I have a full time job and I’m responsible of engine support for the JogAmp Foundation on my spare time as a volunteer. There are only 24 hours a day :clue:
I haven’t done anything with JavaFX nor do I know anything about it really.
But I do know that there are some plans to get JavaFX to Android (how realistic the plans are, do not know) and I know that some ppl have it working on their phone, more or less.
My point wasn’t that ppl should use it now or whatever. It was rather “here, take a look, if You are interested”
Ok thanks. I just tried to explain to you the reality is less appealing than the plans and those demos.