Exposing native surface or opengl handle

[Scott Palmer]

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.bembrick at 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 <krueger at 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
>>