There might be other issues with the early access. The shared NIO buffer
feature should be behavior-neutral if you don't use it. So either there
is some other issue with it, or there is a bug.
Given the number of changes since that early access, both in the JavaFX
13 code base and in the PR it
On 6/7/19 4:40 AM, Johan Vos wrote:
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 maintain
This feature seems very interesting, thanks for doing that! In order to
allow the use of JavaFX as a replacement of Java2D for Earth Observation
applications (i.e. visualizing terabytes of remote sensing data), would
it be possible to create an image without copying data in JavaFX, by
specifying th
The JDK has two mechanisms for introducing "experimental" features:
1. Preview features, which are new language or VM features that are
enabled by a command line switch
2. Incubator modules for new library code
Neither of those address adding API to an existing package / class in an
existing
Hi,
This is good news but may I suggest we do something similar to OpenJDK
who also has explictly marked experimental/preview features shipping in
releases who can naturally get removed in a follow up release.
I would appreciate this in contrast to not getting this feature
integrated at all in FX
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 f
