Why can Scene's only be constructed on the UI thread?
tom.schindl at bestsolution.at
Sat Apr 26 09:52:13 UTC 2014
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
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!)
More information about the openjfx-dev