Sorry, my last reply did not go to the list. That was unintended.

Oracle-Team, please someone comment on this, at least on what should
be done regarding a Jira Issue (or several ones?) to track any
progress on this and collect ideas & requirements.

Best regards,


On Fri, Jun 13, 2014 at 10:41 PM, Robert Krüger <> wrote:
> Thanks for the hint. I think this is similar to what a colleague of
> mine did a while ago as a proof of concept using other com.sun.api
> that then went away. As long as we're bundling the JRE with our
> product and we're desperate enough to get it working, we might do
> something like this but it's of course just a last resort. Lets hope
> someone from Oracle says something.
> On Fri, Jun 13, 2014 at 8:05 PM, Scott Palmer <> wrote:
>> That’s basically it. It isn’t perfect, but its so simple I don’t see why it 
>> can’t be done quickly.  We are already talking about using native code to 
>> render.
>> That said, contains the field we want:
>>     // Native object handle (HWND, or NSWindow*, etc.)
>>     long ptr;
>> You could be evil and hack it now with reflection, but it relies on internal 
>> implementation details.
>> In my application I already create a native window for video preview… though 
>> not as a child of the FX window.  The problem is that there isn’t a 
>> straight-forward, reliable, supported way to get the window handle to use 
>> for the parent (JavaFX) window.  There are ways to hack it, but they aren’t 
>> pretty.
>> Scott
>> On Jun 13, 2014, at 7:55 AM, Robert Krüger <> wrote:
>>> Just for my understanding: Your approach would be to get the native
>>> window handle for the hosting JFX stage, then leave an open space in
>>> the layout for e.g. the player canvas that will be implemented
>>> natively and then create a native child window that just reacts to
>>> move and resize events of its native parent?
>>> On Fri, Jun 13, 2014 at 1:48 PM, Scott Palmer <> wrote:
>>>> 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 <> 
>>>>> 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 <> 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
>>> --
>>> Robert Krüger
>>> Managing Partner
>>> Lesspain GmbH & Co. KG
> --
> Robert Krüger
> Managing Partner
> Lesspain GmbH & Co. KG

Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

Reply via email to