Previews for shared buffer PR
info at michaelhoffer.de
Fri Jun 7 10:17:33 UTC 2019
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.
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.
Dr. Michael Hoffer
Web: mihosoft.eu <http://www.mihosoft.eu/>
Goethe-Zentrum für Wissenschaftliches Rechnen (G-CSC)
60325 Frankfurt am Main
phone: +49 69 798 25254
info at michaelhoffer.de
Am Fr., 7. Juni 2019 um 11:43 Uhr schrieb Johan Vos <johan.vos at gluonhq.com>:
> The PR discussed in https://github.com/javafxports/openjdk-jfx/pull/472,
> addressing https://bugs.openjdk.java.net/browse/JDK-8167148 provides a
> 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 (
> that should get you started.
> - Johan
More information about the openjfx-dev