I have been doing a lot of JavaFX coding this weekend, and I have learned a lot. Mainly, what I learned is subtle changes to your code that can have huge impacts on the performance of the application.
Before I get into that though, some of you may notice the new theme on my blog. I wanted to change it up because my old theme became the most popular one on Wordpress – and I saw several others that used the same theme. I was hoping to keep the look and feel unique, so I changed it around a bit.
Binding – A performance killer
Alright, so lets get into the performance tweaks. The bind keyword is incredibly powerful. I used it all over the place for laying out my UI. For instance – I don’t really find a need for layouts (a common request by many users of JavaFX) because I can ‘bind’ my elements to each other to make sure they lay themselves out correctly.
However, in my experience, it is a performance killer. For my JavaFX competition application, I have several (possibly hundreds) nodes all aligned together. Initially, I wrote it so that their orientations were all bound together. Essentially, if the window width changed, all of the items in the layout would resize accordingly.
This ran incredibly slow, and often locked up. I can not honestly say if this was due to the bind keyword, or some other issues, but as soon as I took the binding out and replaced it with a more traditional ‘resize’ method, things sped way up.
This isn’t to say I took binding out of my application altogether – no way. Instead, I optimized certain nodes that were going to be used often (say several hundreds of times) so that they didn’t need the binding keyword. The ‘containers’ of those nodes (the thing that now lays out all the items) still make use of the bind keyword, but there are far less bindings now. This has sped the application way up.
On Replace – perfection
So binding is really nice because it will update a given attribute when the item it is bound to changes. However, another really powerful aspect of the language is the ‘on replace’ function. It will allow you to call a set of code when a given attribute is replaced. For instance:
public var height : Number on replace prev = next {
if (prev != next) {
// Always reset back to zero for simplicity sake
scrollableNode.translateY = 0;
verticalScroll.reset();
}
checkForScollbarNecessity();
};
This piece of code is used with a ’scroll’ node I have – a node that embeds another node in it and allows you to scroll up and down. What happens here is that the ‘height’ attribute is bound to the stage’s height. When that height is ‘replaced’ (or updated because the stages ‘height’ changed), it will call the function between the { and the }. The ‘prev’ attribute is the original ‘height’ value. The ‘next’ is the new value.
So this code will check to see if those two attributes are the same, and if so, resets the scroll bar (don’t ask why – its an implementation detail). Then it always checks to see whether or not the scroll bar is even needed.
The ‘on replace’ is nice because you can do a bit of code when that attribute changes. In my experience, the on replace is more responsive than a similar binding. There doesn’t appear to be much overhead when using this in my experience.
What happened to ‘do later’
In one of the beta versions of JavaFX, there was this concept of do later. Essentially the code would look like this:
do later {
println("Printing");
}
This would perform the ‘println(“Printing”)’ call on another thread – or at least at some point when the processor was free. What this was really nice for was calling into your backend code. Very infrequently do you want to call off to your Java code on the same thread as your UI code. It can lead to a choppy UI because it has to wait for the processing to complete. This feature was really nice because it was a very simple way to create that new thread.
However, the ‘do later’ syntax is missing from JavaFX 1.1. Well…the syntax is, but the function isn’t. You can still make a do later call with the following code:
FX.deferAction( function() {
println("Printing");
});
It is essentially the same concept, just with a little more typing around it. The original syntax was much nicer, and I hope they re-introduce it at some point, but this bit of code will do the exact same thing.
Conclusions
My coding this weekend has required me to use the bind keyword far less than I would have liked. That may be that I am using it incorrectly or perhaps it is actually a performance hog…I don’t know yet. What I do know is that by using ‘on replace’ to help with my resize issues, and the ‘deferAction’ method to call into the backend code – my program is running pretty quickly. Also, its running very stable – I have had my program running for 3 hours!
I’m hoping that it will shape up well for the competition, but I’m seeing some really good programs being made with Java FX so far! This is going to be tough.