LWJGL-FX (fast JavaFX integration) port to JOGL

classic Classic list List threaded Threaded
13 messages Options
aqd
Reply | Threaded
Open this post in threaded view
|

LWJGL-FX (fast JavaFX integration) port to JOGL

aqd
This post was updated on .
Hello guys! I just ported the LWJGL-FX (fast JavaFX/OpenGL integration) to JOGL. I wonder how I should implement the following stuff correctly?
  1. org.lwjgl.opengl.ContextCapabilities has a huge numbers of boolean fields such as "GL_ATI_fragment_shader" etc, indicating the availability of each extensions. Where are these in JOGL? (not by getExtension("extension name") I hope...)

  2. In their AMD specific RenderStream there is:
    			final ByteBuffer buffer = BufferUtils.createByteBuffer(renderBytes + PAGE_SIZE);
    			final int pageOffset = (int)(MemoryUtil.getAddress(buffer) % PAGE_SIZE);
    			buffer.position(PAGE_SIZE - pageOffset); // Aligns to page
    			buffer.limit(buffer.capacity() - pageOffset); // Caps remaining() to renderBytes
    			pinnedBuffers[i] = buffer.slice().order(ByteOrder.nativeOrder());
    			gl.glBufferData(GL_EXTERNAL_VIRTUAL_MEMORY_BUFFER_AMD, pinnedBuffers[i].remaining(), pinnedBuffers[i], GL_STREAM_READ);

    which seems to rely on the physical position of buffer object (the MemoryUtil.getAddress is to native call), but wouldn't it just break if GC happens to move objects around?? I set the offset to be always 0 in my port and it's still working, with no apparent performance penalty

    EDIT: I tested ported AMD code - the glBufferData(GL_EXTERNAL_VIRTUAL_MEMORY_BUFFER_AMD failed with GL_INVALID_ENUM​: Invalid binding target, thrown by jogamp.opengl.GLBufferStateTracker.checkTargetName! (but works in LWJGL). I modified GLBufferStateTracker to allow it and now it seems to work fine!



  3. They have many calls such as
    glMapBuffer(GL_PIXEL_PACK_BUFFER, GL_READ_ONLY, height * stride, pinnedBuffers[index]);
    which is non-standard. The last argument (buffer) can be ignored, but they also send the parameter length which only exists in glMapBufferRange. It's said in LWJGL docs the parameter is meant to speed things up, but when I use JOGL's glMapBufferRange(target, offset=0, length, access) it always returns null. The standard glMapBuffer(target, access) works for me however. But why?

  4. Why in JOGL document it says GLContext.getGL() may return null outside of GLEventListener calls? In GLPanel it seems available after GLContext.makeCurrent(), which works for my port too. Should I worry about it being changed into null?
aqd
Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

aqd
I published the source here: https://github.com/AqD/JOGL-FX

It includes only the OpenGL to JavaFX node part, since I don't need to embed JavaFX into OpenGL texture. No dependency on LWJGL. The performance seems the same as the original LWJGL version.

However, the RenderStream approach looks incompatible with existing GLAutoDrawable/Animators/GLPanel etc in JOGL (simpler & cleaner IMO) and will requires change in applications.
Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

gouessej
Administrator
aqd, thank you very much, it is really cool, I'm gonna mention it in the main bug report about OpenJFX / JavaFX.

Big kudos to you :) Great job.

Edit.: Is the remaining unported code difficult to port to JOGL?
Julien Gouesse | Personal blog | Website
aqd
Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

aqd
All ported now and 3D webview inside Gears is running fine. I haven't tested the Intel-specific code, and clearly there is some serious memory leak issue with resize. Buffers never get released and each resize allocates more memory.
Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

gouessej
Administrator
It's easy to fix, isn't it? Once the buffer is unbound, you can destroy the direct NIO buffer.
Julien Gouesse | Personal blog | Website
aqd
Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

aqd
How am I supposed to destroy buffers created by jogl JNI code?
Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

Sven Gothel
Administrator
On 08/17/2014 02:06 PM, aqd [via jogamp] wrote:
> How am I supposed to destroy buffers created by jogl JNI code?

Use 'glUnmapBuffer(..)'

We hook to the GL API entries map/unmap
to track the buffer mapping.

See Siggraph 2014 slides
and <https://jogamp.org/bugzilla/show_bug.cgi?id=993#c1>

~Sven



signature.asc (828 bytes) Download Attachment
aqd
Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

aqd
I ported WorldWind to it but somehow it uses more than triple memory (several GBs) than before, and there are weird freeze like 1 in every 5 seconds after I load everything (global country paths, dozens of duck collada models etc) - which might be caused by AWT lock as indicated in VisualVM.

While it shows progress, it's simply not ready for our project. I'll stop here until the OpenGL pipeline can be integrated directly into JavaFX :(

Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

gouessej
Administrator
Your port is valuable. As I already wrote, there are some missing elements that prevent the implementation of a solid JOGL pipeline within OpenJFX / JavaFX. OpenJFX isn't bundled with OpenJDK 1.8, I can't help.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

Sven Gothel
Administrator
On 08/17/2014 09:22 PM, gouessej [via jogamp] wrote:
> Your port is valuable. As I already wrote, there are some missing elements
> that prevent the implementation of a solid JOGL pipeline within OpenJFX /
> JavaFX. OpenJFX isn't bundled with OpenJDK 1.8, I can't help.

I am also not sure whether I can help here,
however - if lead properly w/ detailed information and code I will try to.

In short: If you, 'aqd', like to work and maintain such toolkit binding
within JOGL - we will try our best to support you.

If 'OpenJFX' is 'deployable'/usable we surely want to go that route,
since 'JavaFX' might contain non-free code.

~Sven



signature.asc (828 bytes) Download Attachment
aqd
Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

aqd
This post was updated on .
I found that Java 8u11 is shipped with prism-es2.dll for Windows and it could use the es2 pipeline after adding required classes from the linux version and compiling 4 WGL... classes from OpenJDK into jfxrt.jar.




Since GL calls are native calls, does that mean I could just paint directly on Prism's GLContext by using JOGL calls?




PS: The JOGL/FX integration demo works much better with ES2 pipeline than D3D on Windows - double FPS for AMD_pinned_memory and async PBO!
Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

gouessej
Administrator
Yes, it avoids driver conflicts, nice finding :)
Julien Gouesse | Personal blog | Website
aqd
Reply | Threaded
Open this post in threaded view
|

Re: LWJGL-FX port to JOGL

aqd
In reply to this post by aqd
I made the demo of JOGL on JavaFX ES2 pipeline (Windows). Quite simple actually, the demo code is uploaded to https://github.com/AqD/JOGL-FX




The control trees are preserved and things are running surprisingly well when my node is behind (I put it in TabPane).

But I don't understand why all display lists all gone after each render call - I don't delete them and there is no deletion call from Prism-ES2.




I'll try if I can port WorldWind to it.....