Thanks a lot for the valuable and very encouraging info! I will track that issue and use that for further communication.
Robert On Mon, Jun 23, 2014 at 5:15 PM, Stephen F Northover <steve.x.northo...@oracle.com> wrote: > I'm sorry this thread scrolled away into the bitbucket in the sky. > > Last JavaOne, we wrote a prototype that showed native integration on OS X. > We parented a native sheet dialog in an FX stage and providing an OpenGL > node. The code was a prototype that worked only on OS X. The Open GL node > allowed drawing JOGL and LWJGL to draw on a texture that was created by FX. > This mean that the OpenGL node could take part in FX animations and effects. > > I will attach the prototype code to > https://javafx-jira.kenai.com/browse/RT-36215. I need to find it and make > sure that it still compiles and works. This week is M5 RDP2 and today is > likely to be a write off for a number of reasons. > > https://wiki.openjdk.java.net/display/OpenJFX/8u20 > > Please ping me in the JIRA if the code doesn't show up sometime this week. > The prototype is the basis of one possible implementation and needs some > work. There are other possible implementations and this is not the final > word on the issue. > > Steve > > > On 2014-06-23, 10:03 AM, Robert Krüger wrote: >> >> 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, >> >> Robert >> >> On Fri, Jun 13, 2014 at 10:41 PM, Robert Krüger <krue...@lesspain.de> >> 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 <swpal...@gmail.com> 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, com.sun.glass.ui.Window 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 <krue...@lesspain.de> 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 <swpal...@gmail.com> >>>>> 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 >>>>>>> <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 >>>>>>>> >>>>> >>>>> >>>>> -- >>>>> Robert Krüger >>>>> Managing Partner >>>>> Lesspain GmbH & Co. KG >>>>> >>>>> www.lesspain-software.com >>> >>> >>> >>> -- >>> Robert Krüger >>> Managing Partner >>> Lesspain GmbH & Co. KG >>> >>> www.lesspain-software.com >> >> >> > -- Robert Krüger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com
