Exposing native surface or opengl handle
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
Re: Exposing native surface or opengl handle
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 >
Re: Exposing native surface or opengl handle
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 >>
Re: Exposing native surface or opengl handle
Hi Robert, thank you for pushing this topic again :) For our work we need a way to share the OpenGL context between JavaFX code and native code so that we can render stuff from native code into the JavaFX context. Another question and need is to how to share a context in JavaFX? How is it possible to render the same JavaFX node in OpenGL / graphics device twice? Imagine to show a webcam image on two different positions within a JavaFX app. With pure native OpenGL you could do this via "Context Sharing". But how to do it in JavaFX? Best regards, Tobi Am 13.06.14 08:57, schrieb Robert Krüger: 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
Re: Exposing native surface or opengl handle
I really think that pure JavaFX will always be better if you can, but in some cases you "have" to use external libraries using OpenGL, because you don't have the Java replacement, or it would be a LOT of work to recreate it. Hervé Sent from my iPhone > On Jun 13, 2014, at 14:08, Tobias Bley wrote: > > Hi Robert, > > thank you for pushing this topic again :) > > For our work we need a way to share the OpenGL context between JavaFX code > and native code so that we can render stuff from native code into the JavaFX > context. > > Another question and need is to how to share a context in JavaFX? How is it > possible to render the same JavaFX node in OpenGL / graphics device twice? > Imagine to show a webcam image on two different positions within a JavaFX > app. With pure native OpenGL you could do this via "Context Sharing". But how > to do it in JavaFX? > > Best regards, > Tobi > > > Am 13.06.14 08:57, schrieb Robert Krüger: >> 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 >
Re: Exposing native surface or opengl handle
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 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, 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 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 Ultra
Re: Exposing native surface or opengl handle
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 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, 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 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 r
Re: Exposing native surface or opengl handle
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 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 >> 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, 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 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 pr
Re: Exposing native surface or opengl handle
Hey all, it's great to have a new thread like this. Robert exactly pointed out what we actually need. I have seen an approach to integrate JFX in JOGL and vice versa. This approach is always been a copying of the pixel buffers between those two frameworks. From my perspective this is not a real good approach because of obvious performance issues. Yesterday, I had a better idea. my idea: I know it is very hard to have JFX exposing a real GLCanvas/Context. I used JOGL for quite some time and I know the JFX rendering pipeline a bit. Please correct me if I am wrong. The most applications need some point to draw. The best pointer would be an exposed FBO from Prism that can be used by Jogl/LWJGL. Additionally we would need a possibility to share the JFX OGL-Context with another one, so we could reuse this FBO in a second window. Okay, this wouldn't needed if I could share textures over scenes. I know there is one major limitation. In windows Prism is using DirectX by default, so there won't be a possible interaction with Jogl. I am sure some DirectX guys really like to have there hands on the surface-layer as well ;) Well, to used the Jogl way above we would also need a stable OGL implementation of Prism for Windows. Last time I tried it it was not even comparable. I am not sure why, but OGL on Mac and Linux works pretty good. Matthias -- Matthias Hänel Geschäftsführer/ Managing Director UltraMixer Digital Audio Solutions Am Waldschlößchen 2 01099 Dresden - i...@ultramixer.com http://www.ultramixer.com Am 23.06.2014 um 17:43 schrieb Robert Krüger : > 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 > 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 >>> 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, 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 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 la
RE: Exposing native surface or opengl handle
Here's a link to Steve and Felipe's JavaOne presentation: http://www.parleys.com/play/524ee4dbe4b0ab14e307d7b1/about "Integrating JavaFX with Native Technologies" > This session examines ways that applications can extend JavaFX to use native > technologies, with a focus on OpenGL. It's such a great presentation. Some people do such good work. -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Matthias Hänel Sent: Wednesday, June 25, 2014 12:43 AM To: Robert Krüger Cc: openjfx-dev@openjdk.java.net Subject: Re: Exposing native surface or opengl handle Hey all, it's great to have a new thread like this. Robert exactly pointed out what we actually need. I have seen an approach to integrate JFX in JOGL and vice versa. This approach is always been a copying of the pixel buffers between those two frameworks. >From my perspective this is not a real good approach because of obvious >performance issues. Yesterday, I had a better idea. my idea: I know it is very hard to have JFX exposing a real GLCanvas/Context. I used JOGL for quite some time and I know the JFX rendering pipeline a bit. Please correct me if I am wrong. The most applications need some point to draw. The best pointer would be an exposed FBO from Prism that can be used by Jogl/LWJGL. Additionally we would need a possibility to share the JFX OGL-Context with another one, so we could reuse this FBO in a second window. Okay, this wouldn't needed if I could share textures over scenes. I know there is one major limitation. In windows Prism is using DirectX by default, so there won't be a possible interaction with Jogl. I am sure some DirectX guys really like to have there hands on the surface-layer as well ;) Well, to used the Jogl way above we would also need a stable OGL implementation of Prism for Windows. Last time I tried it it was not even comparable. I am not sure why, but OGL on Mac and Linux works pretty good. Matthias -- Matthias Hänel Geschäftsführer/ Managing Director UltraMixer Digital Audio Solutions Am Waldschlößchen 2 01099 Dresden - i...@ultramixer.com http://www.ultramixer.com Am 23.06.2014 um 17:43 schrieb Robert Krüger : > 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 > 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 >>> >>> 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. >>>> >>>> >&
Re: Exposing native surface or opengl handle
On 13/06/2014 08: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). Although copying is used, I've combined JavaFX and VLC in this fashion for over a year already, and video is smooth and stable -- stable enough to watch full length HD movies, at 20% increased speed (the speed I normally watch them). Of course, if the target machine is barely able to play these, then the extra copying overhead (which is smaller than people think) may be too much. --John
Re: Exposing native surface or opengl handle
On Thu, Jun 26, 2014 at 9:40 AM, John Hendrikx wrote: > > On 13/06/2014 08: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). > > Although copying is used, I've combined JavaFX and VLC in this fashion for > over a year already, and video is smooth and stable -- stable enough to > watch full length HD movies, at 20% increased speed (the speed I normally > watch them). > > Of course, if the target machine is barely able to play these, then the > extra copying overhead (which is smaller than people think) may be too much. Yes and this becomes more and more a problem of not so weak machines when you go to higher resolutions than FHD that you can display well on a Retina display and thus a competitive disadvantage when targeting that market. I agree that for a lot of video applications the copying approach is probably good enough, though. Robert
Re: Exposing native surface or opengl handle
Hey John, Am 26.06.2014 um 10:23 schrieb Robert Krüger : > On Thu, Jun 26, 2014 at 9:40 AM, John Hendrikx wrote: >> >> On 13/06/2014 08: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). >> >> Although copying is used, I've combined JavaFX and VLC in this fashion for >> over a year already, and video is smooth and stable -- stable enough to >> watch full length HD movies, at 20% increased speed (the speed I normally >> watch them). >> >> Of course, if the target machine is barely able to play these, then the >> extra copying overhead (which is smaller than people think) may be too much. > > Yes and this becomes more and more a problem of not so weak machines > when you go to higher resolutions than FHD that you can display well > on a Retina display and thus a competitive disadvantage when targeting > that market. I agree that for a lot of video applications the copying > approach is probably good enough, though. Well, from my perspective it is always a bad idea to memcpy whenever you can avoid it ;) Our applications do a lot more than just display a video image. I really don't want to have a bottleneck by design. Matthias
