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
