This is critical, but I don't think we need to focus on a specific technology like Direct3D or OpenGL. As a first step all we need is a mechanism to get a native reference to the Window. Just like we can with JAWT. I'm guessing that JavaFX doesn't use heavyweight child windows so we could add a new child window that we manage with our own code and it would appear on top of the JavaFX content.
Scott > On Jun 13, 2014, at 3:08 AM, Felix Bembrick <felix.bembr...@gmail.com> wrote: > > I absolutely agree that such a feature is critical for the success and > longevity of JavaFX. I am *really* hoping for some heavily beefed-up 3D > support in a JFX 8.* release or JFX 9. > > I need my graphics toolkit (currently JavaFX) to be able to handle > everything from simple UIs with basic controls to complex 3D > visualisations, just like the underlying graphics API is capable of (i.e. > OpenGL or Direct3D). I strongly suspect though that focusing on OpenGL > exclusively is the only viable way to go from a cost perspective which > would mean JavaFX supporting OpenGL on Windows. > > >> On 13 June 2014 16:57, Robert Krüger <krue...@lesspain.de> wrote: >> >> Hi, >> >> it has been discussed a number of time in the passed but let me >> quickly summarize: >> >> A number of people have requested a feature that provides the ability >> to have native code draw into a surface provided by a JavaFX >> application as fast as technically possible, i.e. with no indirection >> or copying because use cases for this were mostly cases where >> performance was critical, e.g. HD/UHD video players, real-time >> visualization etc. where losing even e few percent would make a >> software written in JavaFX unable to compete with native products >> (e.g. in the video area nobody will use a video player that is not >> able to play the content smoothly that VLC player or Quicktime can on >> the same machine). Some people already have libraries of native code >> that they have built over the years and would like to reuse. I would >> even go so far to say that our product will probably never be able to >> move to JFX (apart from mixing it a bit with Swing, which we currently >> see rather aa a migration strategy and not as the end result) without >> this problem solved. >> >> In the past the reactions/signals from the Oracle team in this respect >> were mixed but some of it indicated that this topic was discussed in >> the past and might be revisited after the release of JFX 8. Now that >> the latter has happened I would like to ask what the plans for this >> are. >> >> Is there a Jira Issue where we can track the progress of it? >> >> If not, does it make sense if I open one, so people (probably the same >> ones that have participated in these discussions in the past like >> Scott and the Ultramixer guys etc.) can collect their >> requirements/thoughts? >> >> Even if Oracle should decide not to do something about it, it would >> still be nice to get pointers in the code base to where this would be >> possible, even if it is non-portable. I know that for our product it >> would be totally OK to have different ways of doing this for each >> platform and to live with the limitation to not be able to manipulate >> the result in the FX scene graph apart from that the position of the >> surface moving with the hosting FX node and as far as I have >> understood others, it is the same for them. >> >> Maybe a Jira issue could also be a good place to bundle information >> about approaches interested parties are willing to pursue. >> >> Thoughts anyone? >> >> Robert >>
