Login  Register

Re: JOGL/JavaFX integration and the future

Posted by Sven Gothel on Feb 25, 2013; 7:00pm
URL: https://forum.jogamp.org/JOGL-JavaFX-integration-and-the-future-tp4028263p4028368.html

On 02/25/2013 07:08 PM, Dejay [via jogamp] wrote:

> Hello,
>
>
> 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.
Here you would already sacrifice concurrency of UI and GL rendering,
i.e. the UI thread will block your GL renderer - e.g. by input events.
Well, this is a JavaFX design decision quite similar w/ AWT and one reason
we have NEWT in place. But well, everyone their own toy.

See http://jogamp.org/jogl/doc/NEWT-Overview.html

> 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()));

Using native parenting w/ NEWT would give you best performance
and it would follow our NewtCanvasAWT and NewtCanvasSWT pattern
of integrating such toolkits w/ NEWT.

Have a look into NewtCanvasSWT implementation,
which should be simple enough to allow a JFX native parenting solution.

This is one solution and I like it the most,
since it allows dropping a platform agnostic NEWT [GL]Window into
another toolkit. NEWT code and the GLEventListener don't need to change
and can be re-parented in and out of your alien toolkit.

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

This currently supports only external AWT objects via JAWTWindow,
but we could extend it.

>
> 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);

Pls use GLDrawableFactory.createProxySurface(..) which already
decides whether to use WrappedSurface / GDISurface.
Have a look at our SWT GLCanvas code to see how to use it properly.

This is the solution to give the alien toolkit users (AWT, SWT, ..)
a way to stay within their world w/o touching NEWT etc.

Ofc you have to deal w/ negative side-effects like lack of UI concurrency
and toolkit dependencies (-> see NEWT approach above).

>
> 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);

That would be another valid but slow way to do it.
Look in GLJPanel how we use it :)

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

Yup, I agree, we have a lot of options to migrate toolkits.
Nevertheless this flexibility allows you to have a choice.

~Sven



signature.asc (911 bytes) Download Attachment