Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (804)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (867)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  supporting WritableImages backed by NIO ByteBuffers  (Read 3565 times)
0 Members and 1 Guest are viewing this topic.
Offline philfrei
« Posted 2019-06-07 21:49:11 »

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:

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

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.


Message: 1
Date: Fri, 7 Jun 2019 11:40:44 +0200
From: Johan Vos <>
To: " List" <>
Subject: Previews for shared buffer PR
Content-Type: text/plain; charset="UTF-8"

The PR discussed in,
addressing 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 (
that should get you started.

- Johan


Message: 2
Date: Fri, 7 Jun 2019 12:17:33 +0200
From: Michael Hoffer <>
To: Johan Vos <>
Cc: " List" <>
Subject: Re: Previews for shared buffer PR
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 Smiley 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 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: <>
Twitter: @mihosoft

Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC)
Kettenhofweg 139
60325 Frankfurt am Main
phone: +49 69 798 25254

music and music apps:
Pages: [1]
  ignore  |  Print  

Riven (397 views)
2019-09-04 15:33:17

hadezbladez (5280 views)
2018-11-16 13:46:03

hadezbladez (2204 views)
2018-11-16 13:41:33

hadezbladez (5544 views)
2018-11-16 13:35:35

hadezbladez (1150 views)
2018-11-16 13:32:03

EgonOlsen (4585 views)
2018-06-10 19:43:48

EgonOlsen (5462 views)
2018-06-10 19:43:44

EgonOlsen (3119 views)
2018-06-10 19:43:20

DesertCoockie (4016 views)
2018-05-13 18:23:11

nelsongames (4708 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!