LWJGL3FX - A sneak peek

Engines, Libraries and Tools
#21

There are rumblings that AWT might itself be hived off into a separate thing too. The fruits of JDK9’s fiddly module system finally ripening.

Cas :slight_smile:

#22

Yes, that’s what I mean. But also be good to know who those interested parties are and what their interests are.

#23

This has me quite excited. Keep the post updated! @Spasi
:slight_smile:

#24

@Spasi I’m watching this space!

I’d love to see some integration happen: I personally really like the framework. I used Swing for years at work, horrible monolithic enterprise Swing apps: personally I hate it! JFX was a welcome improvement. Open JavaFX are seeking more committers. I did have a whinge into the developer thread about my sense that the JavaFX folks are not open to integration. But finding time to commit to, and enough subsequent time to be around long enough to become useful to them is for me a tough ask right now.

#25

Would really like to see this in action!

#26

Java 11 is released
and would be very nice to see this effort to be resumed
so any update about this effort?
OpenGL is going to be deprecated in MacOS in the future
so maybe Vulkan support is more important? given that lwjgl has Vulkan binding already

#27

OpenGL support has effectively been deprecated on Mac OS since 2010 (with 4.1 being the last OpenGL version to work on any Mac OS versions). Apple is persistent in trying to push their own Metal API. I think no one in the world is going to consider writing a Vulkan backend for JavaFX, certainly not as a hobby project. :slight_smile:
In my opinion, it is more likely that someone will come up with an OpenGL implementation based on Metal - as is the case with MoltenVK for Vulkan - than to write a JavaFX rendering backend based on Vulkan (backed by MoltenVK).
Or maybe an OpenGL implementation based on Vulkan based on MoltenVK based on Metal. :smiley:

#28

Based on JavaFX mail archive seems like they are considering creating Vulkan pipeline
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021969.html
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021965.html
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021968.html
and one thing we may need to consider is Google is creating a new desktop&mobile based OS which is Fuchsia
which seems like only support Vulkan rather than OpenGL


so probably Vulkan is inevitable to implement? :slight_smile:

#29

From those mails I do not read any consideration/intent to implement a Vulkan backend.
There are just a bunch of guys (rightfully) bashing Apple for deprecating OpenGL and now searching for a solution to it.
Like I said before, it is far more likely that JavaFX will base on top of another solution providing an OpenGL->something-else adaptation, such as ANGLE, to keep the OpenGL ES API.
See a few posts further in that mailing list: http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021973.html

#30

Last I heard (I can’t find a link atm, but it was from JavaFX maintainers), they’re considering a native Metal backend on macOS. They’d have to ship with MoltenVK for a Vulkan backend and I don’t think they’re interested in that. However, unless Apple decides to suddenly kill all OpenGL apps out there, the current OpenGL support on macOS is more than enough for what JavaFX needs. It’s not like they’ll magically gain performance from Metal, without refactoring the frontend.

On LWJGL3FX, I’ve had a nightmarish summer and a hellish September at work (worth it though). The little free time I had left went to LWJGL maintenance. I’ll report any real progress asap.

In other news, CEF’s #1006 was finally merged a few days ago. D3D only for now, but one can hope…

#31

Hi Spasi, you said "I had written a Prism backend (the part of JavaFX that does the actual rendering) using LWJGL 3. "
Would you mind sharing this part of code in Github?
It would be helpful for other people who is interested in expanding prism implementation e.g. me :slight_smile:

#32
#33

That’s great news. We have a visualization tool for 3D data (2D cross sections and mesh rendering) that is written in JavaFX and we think that one of the bottle neck is copying textures onto the Graphics Card in the application thread (as far as we understand) as well as the lack of texture sharing between different image views/3D. This sounds very exciting!

#34

seems like e(fx)clipse provides an very nice alternative solution?

#35

Hmmm interesting. I think we’ll be needing it to be part of OpenJFX 11 to take it properly seriously though.

Cas :slight_smile:

#36

What’s the current status?

#37

The lwjgl3 driftfx branch now includes bindings for DriftFX, can be used like this: HelloDriftFX. WIP and performance is bad (see this post for details), but it works.

#38

@Spasi
Although heavily WIP, will this work on Mac? If not now, is it possible in the future?

#39

Yes, DriftFX has a macOS/CGL implementation. One issue is that currently DriftFX creates an OpenGL 4.1 core+debug profile context on all platforms and there’s no way to change/configure this.

#40

Does this mean that the window is managed by DriftFX(JavaFX)? instead of GLFW? If so, that’s pretty interesting. I’ll have to prepare my engine for this. I really hope I can adopt JavaFX!