Oracle Blog

Articles related to JavaFX Script

Best Practices for JavaFX Mobile Applications

As everybody who is interested in JavaFX will know by now, JavaFX Mobile was released a short while
ago. It was a hell of a ride, that's for sure. I felt so exhausted, I did not even have the energy to blog during the release...

But by now I feel recovered and want to start a little series about lessons we have learned while preparing the release and give some hints how to improve the performance of JavaFX Mobile applications.

WARNING: The tips I am giving here are true for the current version of JavaFX Mobile, which is part of the JavaFX 1.1 SDK. In future versions the behavior will change, the
current bad performance of the mentioned artifacts will be optimized away or at least significantly improved. Everything I am writing about here is a snap-shot, nothing should be understood as
final!

Item 1: Avoid unnecessary bindings

Bindings are very convenient, without any doubt one of the most valuable innovations in JavaFX Script. Unfortunately they come with a price. The generated boiler-plate code is usually not as small and
fast as a manual implementation would be. Especially complex dependency-structures tend to impose a severe penalty on performance and footprint.

For this reason it is recommended to avoid bindings as much as possible. Often the same functionality can be implemented with triggers. One should not use bindings to avoid the hassle of dealing with the initialization order. And it certainly makes no sense to bind to a constant value.

Lazy bindings are most of the time (but not always!) faster if a bound variable is updated more often then read, but they are still not as fast as manual implementations.

Example

A common use-case is a number of nodes which positions and sizes depend on the stage-size. A typical implementation uses bindings to achieve that.

Here we will look at a simple example, which resembles such a situation. The scene consists of three rectangles which are laid out diagonally from the top-left to the bottom-right. The size of the rectangle is a quarter of the screen-size. Code Sample 1 shows an implementation with bindings.

The first question one should think about is wether the bindings are really necessary. On a real device the screen-size changes only when the screen orientation is switched (provided that the device supports this functionality). If our application does not support screen rotation, the layout can be defined constant.

One possible solution to reduce the number of bindings is shown in Code Sample 2. Two variables width and height are introduced and bound to stage.width and stage.height respectively. Their only purpose is to provide triggers for stage.width and stage.height, since we do not want to override the original triggers. Position and size of the rectangles are calculated manually in the triggers.

Yeah, but I think ultimately, the best desirable solution is to have the compiler be smart enough to optimize out the binding cases so that the developer wouldn't have to worry about extraneous, unnecessary bindings. Kind of like what HotSpot does now with loops and the inlining stuff. Binding is such a core concept to JavaFX that I would really hate to be self conscious about using it.

I encountered also a huge performance issue on mobile 6.1 with early access on my HTC. True I use a lot of binds (really needed to decouple the view with the model) and the screen counts 24 shapes 24 buttons which are bind to my model objects in. All instantiated in the beginning of the app.

It takes 1 min 30 seconds to launch the app ! ( on my iMac it's less than 1 second ) Once started it works kind smoothly could be better but considering it's only a mobile with single core and less fast on speed it works well. An other example is a creation at runtime if customnode with 2 shapes, 3 Textboxes and a button also with some binding takes 5 seconds ! The latter is a real DON'T LIKE.

So apparently the instantiations of controls with lots of binds takes a huge charge for the mobile VM. For the moment the best thing you can do if you have still some binds in your app is trying to creating them all ( sequence of nodes ) in the start up of the app and later on, switch or assign them to the scene view dynamically with your customized views or nodes.

My point here is optimizing useless binds yes, but for useful and needed binds to have the MVC pattern implemented as much as possible I say that there is still a lot of work to do in finding an increase of performance ( say factor 10 ) on the mobile platform.

I don't know if there are any benchmarks available but if so I would like to post some results there too.

I hope that the next version of javaFX mobile will have some optimizations especially on performance. I don't know if window mobile 6.5 will bring me some boost but I doubt it really.