Current takes on JavaFX issues

Java 2D JavaFX
#1

Back almost exactly two years ago (Sep 2017) we had a discussion about problems with JavaFX. I’m linking @princec’s reply which is followed immediately by @Riven and others.

With JavaFX split off, there was some hope that at least some of these issues could be addressed. JavaFX 13 has been released. What progress has been made? Here is a link to the JavaFX 13 Release Notes.

For example, JDK-8167148 Add native rendering support by supporting WritableImages backed by NIO ByteBuffers
How much does this improve rendering?

This still-open matter is more pertinent?
JDK-8091324 Allow FX to interoperate with 3rd party (native) OpenGL visualizations

The initial post is very old, but there is recent activity originating from work by @gouessej pertaining to NEWT. Bug 607 - JavaFX 2+ and JOGL should work together, comments 27, 28.
Also Bug 1364 - Add JavaFX Support for NEWT utilizing native Window parenting via NewtCanvasJFX

My knowledge of behind-the-scene’s graphics processing is limited. I’ll benefit from any background or explanatory info included in replies, where it isn’t too much trouble.

#2

Here’s an example. Looks impressive, people make it sound impressive, except there’s this little detail of 30% CPU usage. I.e. it’s crap and not a solution for real-time rendering or video playback. I recently ported LWJGL-FX to lwjgl3/glfw and JavaFX 13 to give it a try (repo will be updated soon). I found it’s actually worse than the PixelWriter API:

a) There’s no way to synchronize with JavaFX in order to render concurrently with double/triple-buffering.
b) The “native” rendering API does not support a row stride in the pixel data (PixelWriter did), which means reduced readback performance.

The solution to both problems is, ironically, copying the pixel data.

I also recently added driftfx bindings to lwjgl3. It’s looking promising, follow this issue for more. It’s a noble approach if you don’t want to mess with JavaFX internals too much and it will probably become a viable solution when it matures (needs more work atm). But I also think that a JavaFX fork with a LWJGL3FX-style backend would be the best approach. Another interesting approach is writing a bgfx implementation, which would get us automatic support for OpenGL/D3D9/D3D12/Vulkan/Metal (i.e. stable top performance on every platform).

#3

philfrei, just as a reminder, NewtCanvasJFX (from JOGL) just works like a charm, it’s in the latest release candidate of JOGL 2.4. If you need some help to make it work in an engine or a framework, let me know. I plan to use it in ardor3d-jogl-jfx but it has a very low priority for me as the few corporations using JogAmp’s Ardor3D Continuation seem to stick to Swing right now and T.U.E.R uses NEWT.

#4

Hello

I’ve just written a tiny tutorial with a small example (about 100 lines of code) using JOGL 2.4.0, OpenJDK 14 and OpenJFX 14:

#5

… redacted