It’s is starting to look like the ability to write directly into image buffers in JavaFX is soon to be.
I heard about this on the OpenJFX mailing list today.
To subscribe to the list, they give the following:
[quote]To subscribe or unsubscribe via the World Wide Web, visit
https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
or, via email, send a message with subject or body ‘help’ to
openjfx-dev-request@openjdk.java.net
[/quote]
Maybe I should just copy and paste the messages that came in today. I can’t post as quote due to 90% threshold. I’d give a link, but I can’t figure out the site.
EVERYTHING THAT FOLLOWS IS A QUOTE.
Message: 1
Date: Fri, 7 Jun 2019 11:40:44 +0200
From: Johan Vos johan.vos@gluonhq.com
To: “openjfx-dev@openjdk.java.net List” openjfx-dev@openjdk.java.net
Subject: Previews for shared buffer PR
Message-ID:
CABxFH2FMLzZx5WPx6FHs7RJezHBEgu5AhKBYx4uu3vttg70Y1Q@mail.gmail.com
Content-Type: text/plain; charset=“UTF-8”
The PR discussed in https://github.com/javafxports/openjdk-jfx/pull/472,
addressing https://bugs.openjdk.java.net/browse/JDK-8167148 provides a very
much wanted feature. It is important that things are done in the right way
so that the code can be maintained in the long-term future.
Therefore, feedback on this PR is extremely important before we can
consider merging it. Once this PR is merged, there is no easy way back. It
is possible to add more functionality, hence my preference is to only
implement the functionality that is safe and stable, while allowing other
functionality to be added later or by third-party extensions. (e.g.
(avoiding) copying from/to GPU)
To make it easier to give feedback, we’ve build early access versions of
SDK’s including this PR. Note that the PR is not merged, hence not
available in the regular EA downloads!
If you want to give it a try, download the SDK’s from the URL’s below.
There is a test in tests/manual/graphics/PixelBufferPerformanceTest (
https://github.com/arapte/openjdk-jfx/blob/JDK-8167148-NIO-ByteBuffer/tests/manual/graphics/PixelBufferPerformanceTest.java)
that should get you started.
https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-jmods.zip
https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-sdk.zip
https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-jmods.zip
https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-sdk.zip
https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-jmods.zip
https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-sdk.zip
- Johan
Message: 2
Date: Fri, 7 Jun 2019 12:17:33 +0200
From: Michael Hoffer info@michaelhoffer.de
To: Johan Vos johan.vos@gluonhq.com
Cc: “openjfx-dev@openjdk.java.net List” openjfx-dev@openjdk.java.net
Subject: Re: Previews for shared buffer PR
Message-ID:
CAMWeGnEyO9v-wm7c9PYt10vb__K57JmyFFtJbWhO-869L3HYLA@mail.gmail.com
Content-Type: text/plain; charset=“UTF-8”
Hi Johan, hi all,
I want to share some thoughts on native buffer support aka JDK-8167148:
As I and many others have pointed out in the past, better native buffer
support is a great opportunity for JavaFX to leverage the power of external
visualization libraries and frameworks. It is a great way for community
members to contribute new features to the scene graph. For many of us in
the scientific world it opens the door to finally using JavaFX as a
replacement for native solutions since we can integrate performance
critical components into the scene graph.
In the past I have been a little grumpy about the fact that little progress
has been made on this front for quite some time. For me, it was almost
impossible to promote JavaFX in favor of Swing or Qt. Projects like DriftFX
have shown that there’s interest in even more efficient solutions than just
CPU based buffer sharing as it has been proposed by JDK-8167148.
But things are changing. From a performance perspective DriftFX is by far
the most promising solution. But for me, a stable solution as proposed in
JDK-8167148 is even more important as it gives DriftFX the ability to use
it as fallback, i.e., it will work much more reliably even if direct
texture sharing does not work for some reason (drivers, hardware
limitations etc.). Ambarish Rapte has started to work on a PR that already
provides initial buffer support. I tried his implementation and found that
render performance increases by roughly 50% compared to the classic
PixelWriter approach. This is a significant improvement. For me, it worked
exactly as advertised 
Thanks for this contribution.
What’s next?
I will reanimate my experiments with a shared memory rendering solution
based on boost IPC. That allowed me in the past to render full HTML5
(including WebGL) in JavaFX (see https://github.com/miho/VFXWebKit). But
due to the performance limitations the project wasn’t really practical. In
general, we should allow foreign rendering technologies to be integrated
into the scene graph. That will ensure that JavaFX will stay relevant for a
very long time. JDK-8167148 is a very important step in this direction.
Johan, thanks for providing the preview builds. They make testing really
easy. Ambarish, thank you so much for your PR.
Regards,
Michael
–
Dr. Michael Hoffer
Web: mihosoft.eu http://www.mihosoft.eu/
Twitter: @mihosoft
Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC)
Goethe-Universit?t
Kettenhofweg 139
60325 Frankfurt am Main
phone: +49 69 798 25254
info@michaelhoffer.de