Posted by Dejay on Feb 25, 2013; 6:08pm
URL: https://forum.jogamp.org/JOGL-JavaFX-integration-and-the-future-tp4028263p4028365.html

Hello,

I'm currently waiting for the remaining prism code of JavaFX 8 to be made open source (soon). IMHO the best way to go about this is to develop a JOGLGraphicsPipeline for JavaFX, then you can write a custom JavaFX node and use JOGL commands in the renderer thread. That would be cross platform (except for WinRT tablets without GL). I have experimented with this under OSX to integrate an IOSurface into a JavaFX application and it works without sacrificing performance, although a bit hacky yet.

I guess it would also be possible to use JavaFX to render into an offscreen surface and use it as a texture, but IMHO using JavaFX as your application framework (threading, events, properties, css, bindings etc are quite awesome) and using custom GL nodes is a better way.

I've chatted with Julien Gouesse a bit on JavaGaming but didn't have much time working on stuff since then. I have pushed my current highly experimental efforts to https://bitbucket.org/dejayberlin/joglfxpipeline if anyone cares to check it out. It's not working yet.



Currently I'm still stuck constructing the "Presentable" from an existing glass window:
public JOGLPresentable(PresentableState state, JOGLContext context)

The idea is you have an existing window from glass (PresentableState has a "WinView" and that has a "WinWindow" and all give the same long for getNativeHandle / getNativeView
and get a native view handle (long). You don't want jogl to handle window / input events, since glass is handling all that. All calls to the JOGLPipeline happen in the "QuantumRendererThread" which would become the GL thread and would be fine.
I assume the "state.getWindow().getNativeHandle()" the glass windows gives me is the HWND under windows. How would I go about creating a GLContext with a hardware swap chain or double buffer for this existing HWND? I guess since win/mac perform their own desktop composition a swap chain is fastest?


Do I create a child window? That seems like overhead.
com.jogamp.newt.NewtFactory.createWindow(view.getNativeView(), screen, new GLCapabilities(GLProfile.getDefault()));

Do I use the NativeWindowFactory and somehow create a GLSurface from that?
javax.media.nativewindow.NativeWindowFactory.getNativeWindow(winObj, config)

Do I use jogamp.nativewindow.WrappedSurface?
UpstreamSurfaceHookMutableSize upstream = new UpstreamSurfaceHookMutableSize(view.getWidth(), view.getHeight());
AbstractGraphicsConfiguration agc = new MutableGraphicsConfiguration(screen, null, null);
jogamp.nativewindow.WrappedSurface ws = new WrappedSurface(agc, view.getNativeView(), upstream, false);

Or should one create an offscreen surface and copy the rendered content into the window?
javax.media.opengl.GLDrawableFactory.getDesktopFactory().createOffscreenDrawable(device, caps, chooser, width, height);


The truth is I don't really know what I'm doing here since I'm a little overwhelmed with the many options =)


Thanks in advance,
Dejay

PS, about licensing, it should be fine for applications:
http://fxexperience.com/2013/02/february-open-source-update/#more-2496

Richard Bair wrote

There have been some question about licensing on iOS as Apple doesn’t allow for GPL licensed applications in their app store. OpenJFX and OpenJDK are both licensed with the same GPLv2 with Classpath Extension. My understanding (and I’m not a lawyer) is that this means that if you take OpenJFX + OpenJDK (minus any binary stubs released under a different license), then you can safely combine this with your application and release your application under your own license as a single application co-bundle. You can do the same with the GA release of JavaFX + JavaSE. The difference is that we do not yet have iOS / Android on our official release roadmap, so that for the time being, the only way to use JavaFX on iOS is via OpenJDK / OpenJFX. I can imagine this would make open source guys smile (open source goes where closed source does not!). This is also why we’ve been prioritizing open source so highly for the last little while — when OpenJFX can be built without any binary stubs, then there is nothing stopping you from taking OpenJFX with iOS port + OpenJDK and creating commercial applications that can be sold in the iOS app store.