Re: Why can Scene's only be constructed on the UI thread?
The patch tries to solve the issue by deferring the construction of Scene in PopupWindow, but the issues I ran into just show that it's not enough. In order to fix RT-17716, we need Scene construction outside of the thread. Looking at the Scene code, it seems that there are not that many places where app thread is necessary. The Scene's peer is created only when added to a Window (which is good), but there are still calls that need to be synchronized or transferred to the app thread. Like when a Node is removed from a Scene, it's peer is immediately disposed. And also snapshots require peers (i.e. Scene in a Window), but I guess we can live with that. I'm also not sure about accessibility, maybe the code would need some adjustments as well. -Martin On 04/28/2014 08:18 PM, Kevin Rushforth wrote: Some of this was looked at while trying to solve RT-17716 https://javafx-jira.kenai.com/browse/RT-17716 (see Martin's patch). I think it would be worth considering relaxing the restriction on constructing Scene and Window (maybe Stage, but I don't think there is a benefit for that one), but it seems that Martin ran into some issues with his specific patch. -- Kevin Richard Bair wrote: Hi, Actually I don’t know of any reason why Window and Scene cannot be created and initialized on any thread. Each of these has a peer, and the *peer* we can’t update except on the right thread (or with care, these are OS specific restrictions or issues). But I don’t see any reason why the Java side cannot be initialized on any background thread. And in fact, that was always my intent for exactly these reasons, having experienced all this pain in Swing before firsthand. Its just work that needs to be done, contributions welcome :-) Richard On Apr 26, 2014, at 12:48 PM, Tony Anecito adanec...@yahoo.com wrote: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
For a Node to have a peer to dispose, it must have been attached to a live Scene, right, which must be done on the app thread. Requiring nodes to be removed from a live Stage/Scene on the app thread doesn't seem like a big deal. To snapshot you could just throw an exception if someone tries to snapshot a node that isn't a part of a live scene. Also no big deal. Then if a Scene's peer is only constructed when it's attached to a live Stage, there's nothing to do there. So it seems like it shouldn't be too hard? On Tue, Apr 29, 2014 at 8:39 AM, Martin Sladecek martin.slade...@oracle.com wrote: The patch tries to solve the issue by deferring the construction of Scene in PopupWindow, but the issues I ran into just show that it's not enough. In order to fix RT-17716, we need Scene construction outside of the thread. Looking at the Scene code, it seems that there are not that many places where app thread is necessary. The Scene's peer is created only when added to a Window (which is good), but there are still calls that need to be synchronized or transferred to the app thread. Like when a Node is removed from a Scene, it's peer is immediately disposed. And also snapshots require peers (i.e. Scene in a Window), but I guess we can live with that. I'm also not sure about accessibility, maybe the code would need some adjustments as well. -Martin On 04/28/2014 08:18 PM, Kevin Rushforth wrote: Some of this was looked at while trying to solve RT-17716 https://javafx-jira.kenai.com/browse/RT-17716 (see Martin's patch). I think it would be worth considering relaxing the restriction on constructing Scene and Window (maybe Stage, but I don't think there is a benefit for that one), but it seems that Martin ran into some issues with his specific patch. -- Kevin Richard Bair wrote: Hi, Actually I don’t know of any reason why Window and Scene cannot be created and initialized on any thread. Each of these has a peer, and the *peer* we can’t update except on the right thread (or with care, these are OS specific restrictions or issues). But I don’t see any reason why the Java side cannot be initialized on any background thread. And in fact, that was always my intent for exactly these reasons, having experienced all this pain in Swing before firsthand. Its just work that needs to be done, contributions welcome :-) Richard On Apr 26, 2014, at 12:48 PM, Tony Anecito adanec...@yahoo.com wrote: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
The snapshot methods already do a thread check and throw an exception if they are called on a thread other than an app thread. -- Kevin Mike Hearn wrote: For a Node to have a peer to dispose, it must have been attached to a live Scene, right, which must be done on the app thread. Requiring nodes to be removed from a live Stage/Scene on the app thread doesn't seem like a big deal. To snapshot you could just throw an exception if someone tries to snapshot a node that isn't a part of a live scene. Also no big deal. Then if a Scene's peer is only constructed when it's attached to a live Stage, there's nothing to do there. So it seems like it shouldn't be too hard? On Tue, Apr 29, 2014 at 8:39 AM, Martin Sladecek martin.slade...@oracle.com wrote: The patch tries to solve the issue by deferring the construction of Scene in PopupWindow, but the issues I ran into just show that it's not enough. In order to fix RT-17716, we need Scene construction outside of the thread. Looking at the Scene code, it seems that there are not that many places where app thread is necessary. The Scene's peer is created only when added to a Window (which is good), but there are still calls that need to be synchronized or transferred to the app thread. Like when a Node is removed from a Scene, it's peer is immediately disposed. And also snapshots require peers (i.e. Scene in a Window), but I guess we can live with that. I'm also not sure about accessibility, maybe the code would need some adjustments as well. -Martin On 04/28/2014 08:18 PM, Kevin Rushforth wrote: Some of this was looked at while trying to solve RT-17716 https://javafx-jira.kenai.com/browse/RT-17716 (see Martin's patch). I think it would be worth considering relaxing the restriction on constructing Scene and Window (maybe Stage, but I don't think there is a benefit for that one), but it seems that Martin ran into some issues with his specific patch. -- Kevin Richard Bair wrote: Hi, Actually I don’t know of any reason why Window and Scene cannot be created and initialized on any thread. Each of these has a peer, and the *peer* we can’t update except on the right thread (or with care, these are OS specific restrictions or issues). But I don’t see any reason why the Java side cannot be initialized on any background thread. And in fact, that was always my intent for exactly these reasons, having experienced all this pain in Swing before firsthand. Its just work that needs to be done, contributions welcome :-) Richard On Apr 26, 2014, at 12:48 PM, Tony Anecito adanec...@yahoo.com wrote: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
Hi, Actually I don’t know of any reason why Window and Scene cannot be created and initialized on any thread. Each of these has a peer, and the *peer* we can’t update except on the right thread (or with care, these are OS specific restrictions or issues). But I don’t see any reason why the Java side cannot be initialized on any background thread. And in fact, that was always my intent for exactly these reasons, having experienced all this pain in Swing before firsthand. Its just work that needs to be done, contributions welcome :-) Richard On Apr 26, 2014, at 12:48 PM, Tony Anecito adanec...@yahoo.com wrote: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
Some of this was looked at while trying to solve RT-17716 https://javafx-jira.kenai.com/browse/RT-17716 (see Martin's patch). I think it would be worth considering relaxing the restriction on constructing Scene and Window (maybe Stage, but I don't think there is a benefit for that one), but it seems that Martin ran into some issues with his specific patch. -- Kevin Richard Bair wrote: Hi, Actually I don’t know of any reason why Window and Scene cannot be created and initialized on any thread. Each of these has a peer, and the *peer* we can’t update except on the right thread (or with care, these are OS specific restrictions or issues). But I don’t see any reason why the Java side cannot be initialized on any background thread. And in fact, that was always my intent for exactly these reasons, having experienced all this pain in Swing before firsthand. Its just work that needs to be done, contributions welcome :-) Richard On Apr 26, 2014, at 12:48 PM, Tony Anecito adanec...@yahoo.com wrote: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
Read the jira ticket i referenced in my initial reply - tooltips and context menus create a window instance (=glass) and calls on glass have to be made on the javafx thread. Tom Von meinem iPhone gesendet Am 27.04.2014 um 05:14 schrieb Felix Bembrick felix.bembr...@gmail.com: Why do tooltips and context menus matter? Is it because they will later be instantiated on the wrong thread when they pop up? On 27 Apr 2014, at 7:04, Tom Schindl tom.schi...@bestsolution.at wrote: If you don't use Tooltips context menus you can construct the scenegraph in any thread. Tom Von meinem iPhone gesendet Am 26.04.2014 um 21:48 schrieb Tony Anecito adanec...@yahoo.com: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
Cool, thanks. On 27 April 2014 16:35, Tom Schindl tom.schi...@bestsolution.at wrote: Read the jira ticket i referenced in my initial reply - tooltips and context menus create a window instance (=glass) and calls on glass have to be made on the javafx thread. Tom Von meinem iPhone gesendet Am 27.04.2014 um 05:14 schrieb Felix Bembrick felix.bembr...@gmail.com : Why do tooltips and context menus matter? Is it because they will later be instantiated on the wrong thread when they pop up? On 27 Apr 2014, at 7:04, Tom Schindl tom.schi...@bestsolution.at wrote: If you don't use Tooltips context menus you can construct the scenegraph in any thread. Tom Von meinem iPhone gesendet Am 26.04.2014 um 21:48 schrieb Tony Anecito adanec...@yahoo.com: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
You said so eloquently what I was trying to say so lamely! On 27 April 2014 16:36, Felix Bembrick felix.bembr...@gmail.com wrote: Cool, thanks. On 27 April 2014 16:35, Tom Schindl tom.schi...@bestsolution.at wrote: Read the jira ticket i referenced in my initial reply - tooltips and context menus create a window instance (=glass) and calls on glass have to be made on the javafx thread. Tom Von meinem iPhone gesendet Am 27.04.2014 um 05:14 schrieb Felix Bembrick felix.bembr...@gmail.com : Why do tooltips and context menus matter? Is it because they will later be instantiated on the wrong thread when they pop up? On 27 Apr 2014, at 7:04, Tom Schindl tom.schi...@bestsolution.at wrote: If you don't use Tooltips context menus you can construct the scenegraph in any thread. Tom Von meinem iPhone gesendet Am 26.04.2014 um 21:48 schrieb Tony Anecito adanec...@yahoo.com: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Why can Scene's only be constructed on the UI thread?
I'm trying (mostly in vain) to optimise the startup time of my app. It takes about a second to build the main GUI via FXMLLoader.load() - probably because the GUI is getting a little bit complex but I think mostly because it's all running interpreted, as it's one of the first things the app does. Later loads of the same GUI take more like 100-200msec, presumably because HotSpot went in and compiled it. But that's kind of useless for me. It's the first load that counts. So I figured I'd bring up a stage of the right size early with just a logo and a loading indicator, and load the root Node of my UI on a background thread so the user has something to look at for a moment whilst it's hauling itself into memory. My first attempt was to show the splash and then load the UI. Didn't work of course, because the UI thread didn't get a chance to render. So then I put it inside a Platform.runLater which also didn't work, the splash didn't appear quickly enough. So then I tried putting it in a background thread. This got the right splash behaviour but it didn't work out of the box: my GUI has tooltips and context menus in it. These attempt to construct a Scene at load time, which of course fails because it's not on the GUI thread. Once I commented those out, I got the behaviour I wanted, but of course at the cost of features. Given that these Scene's are not being rendered as they're not visible or interactable, what's the reason they have to be built on the UI thread? Also does anyone have any advice for making JFX8 apps that start really fast? I tried parallelising most of the work my app is doing at startup and annoyingly it hardly helped at all. Not sure why yet: perhaps the JVM or the operating system is busy using the other core so all my threads get scheduled onto the same chip.
Re: Why can Scene's only be constructed on the UI thread?
On 26.04.14 11:42, Mike Hearn wrote: I'm trying (mostly in vain) to optimise the startup time of my app. It takes about a second to build the main GUI via FXMLLoader.load() - probably because the GUI is getting a little bit complex but I think mostly because it's all running interpreted, as it's one of the first things the app does. Later loads of the same GUI take more like 100-200msec, presumably because HotSpot went in and compiled it. But that's kind of useless for me. It's the first load that counts. So I figured I'd bring up a stage of the right size early with just a logo and a loading indicator, and load the root Node of my UI on a background thread so the user has something to look at for a moment whilst it's hauling itself into memory. My first attempt was to show the splash and then load the UI. Didn't work of course, because the UI thread didn't get a chance to render. So then I put it inside a Platform.runLater which also didn't work, the splash didn't appear quickly enough. So then I tried putting it in a background thread. This got the right splash behaviour but it didn't work out of the box: my GUI has tooltips and context menus in it. These attempt to construct a Scene at load time, which of course fails because it's not on the GUI thread. Once I commented those out, I got the behaviour I wanted, but of course at the cost of features. I think you are seeing https://javafx-jira.kenai.com/browse/RT-17716 Given that these Scene's are not being rendered as they're not visible or interactable, what's the reason they have to be built on the UI thread? Also does anyone have any advice for making JFX8 apps that start really fast? I tried parallelising most of the work my app is doing at startup and annoyingly it hardly helped at all. Not sure why yet: perhaps the JVM or the operating system is busy using the other core so all my threads get scheduled onto the same chip. At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? We provide currently only commandline ant integration and require to run on Java8 (you don't need to use Eclipse to make use of it!) Tom
Re: Why can Scene's only be constructed on the UI thread?
At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
If you don't use Tooltips context menus you can construct the scenegraph in any thread. Tom Von meinem iPhone gesendet Am 26.04.2014 um 21:48 schrieb Tony Anecito adanec...@yahoo.com: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
Why do tooltips and context menus matter? Is it because they will later be instantiated on the wrong thread when they pop up? On 27 Apr 2014, at 7:04, Tom Schindl tom.schi...@bestsolution.at wrote: If you don't use Tooltips context menus you can construct the scenegraph in any thread. Tom Von meinem iPhone gesendet Am 26.04.2014 um 21:48 schrieb Tony Anecito adanec...@yahoo.com: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
