Use Layout: For positioning node always use Layout. There are plenty of layout available such as HBox, VBox, Tile, Flow and Stack. If we need any custom layout you can use Container or Panel. Position node using layoutX and layoutY attributes. Use translateX and translateY for Animation.

Consolidate Theme Attributes : We can reuse many theme related objects such as Font, Color, Paint, Image. Eg: If we use same Font for many Label/Text, we can use the same Font instance instead of creating one each for each instance of Node. This consolidation also allow us to customize the UI. You may refer to Theme used in Calendar sample. Also share Image instances such as default-image, place-holder image etc across multiple objects.

Bind with Caution: I have stressed on this in one of my previous post. Repeating the same again. Use this mostly for wiring model to view. Minimize use for other purpose such as layout of Nodes. Also better to avoid chaining of binds, its very problematic and difficult to debug.

JavaFX for View: There is a tendency to write entire application using pure JavaFX. This may be fine for small widget like application or samples. But when you write real business application we need to push out the business logic, IO operations and non-ui related code to Java layer. Use JavaFX Async APIs + Callback methods so as to execute these code outside Event-Dispatch-Thread. HttpRequest API demonstrates use of this approach.

Reduce use of Effects: In many cases we may need to have static effects in UI, such as nice gradient for background, font effects etc. If these effects are static, its always better to use Image instead of effect API.

Stroke Vs Fill: Instead of using stroke attribute for shape, we may use nested shapes with fill attribute. Example: For creating a stroke for Rectangle, we can create two instances of Rectangle overlapping, with the inner Rectangle smaller than outer Rectangle. This will have better performance compared to use of stroke attribute.

Avoid Class-Path in Manifest: When we add various jars as library to Netbeans, these jars are directly referenced in Class-Path of Manifest file of the application jar. When deployed, this will force to download all jars before start of application. Concept of lazy download will not work. Also there will be an attempt to make an unnecessary network connection, even though resources such as plugin.jar, javaws.jar etc are not hosted. This will increase initial applet/javaws startup time.

Use Image.width & Image.height: If we need to show a thumbnail of large image, its better to specify its width and height Image object itself rather than resizing the ImageView using fitWidth and fitHeight attribute. This will reduce the memory used to hold the image.

Provide Startup Feedback: Many a times people get bored due to lack of proper feedback during startup. This creates a notion of increased startup time. Except for small use-cases such as advertisements, RIA’s do have some startup time. It will be nice to provide a Custom Splash Screen and even better a Progress Listener UI to give useful feedback.

Tips for Mobile: : Joshua Marinacci has listed some useful tips for mobile.

One of the previous post [Applet Startup Time] provided a way to measure start-up time of JavaFX Applets. Many responded with requested information (Thanks a lot!). One of the main concern raised was high start-up time for “Without JavaFX Runtime”. This is high because it includes time taken to download and install JavaFX Runtime.

Unfortunately there was no way to notify the user about exact progress of this. Hence user will not be able to differentiate between download and install of “JavaFX Runtime” and “JavaFX Application”.

Recent JavaFX Update 1.2.3 reduced the download size and start-up time. You can notice this change by trying out the start-up time measurement applet again.. But still it doesn’t provide a way to exactly notify the start-up progress. We can only specify a custom splash-screen as specified here.

Now we can implement custom progress listener with actual values. We can use the same approach for JavaFX applications as well. There is minor issue in using this feature with JavaFX Applet deployed using dtfx.js. This script is not updated to utilize this feature. So for now we need to explicitly hide the default splash screen by invoking JavaScript method hideOverlay as shown in ProgressListenerFX.html

I did some monitoring with JConsole. It was giving consistent 60 fps for 50 nodes with average 13% CPU usage. JConsole details available here. I’ll leave it to experts to come up with proper conclusion…

There is significant performance improvement done in different components of JavaFX for next release.. Stay tuned.. I will share the statistics with exactly same test and same system so as to compare the improvement..

Anyway back to the topic.. Is it always good to compress the jar while deploying the Java/JavaFX application? What will be its impact on startup time? Or may be I was doing too much pack and unpack of luggage during vacation and hence the thought is still lingering in my mind?!

I think the answer depends on the application and target users. Pack helps to compress the jar file size (reduce download time). But it may increase the start-up time due to additional step – unpack. So if the application is too small, it may be better not to use compressed jar. Also if the target audience has very good bandwidth, then user may not see the benefit of reduced download time.

Applet – Pack

Applet – No-Pack

Note: Above example is not the best to demonstrate any significant difference in warm start-up time

Also set update check to background in jnlp files as shown below.. Please refer to tech tip on start-up time for more information.

<update check="background"/>

JavaFX packager was generating jnlp files with missing / for close tag for applet-desc – param tag. Due to this any subsequent tags were getting ignored. So we need to ensure that all tags are properly closed. This issue with javafxpackager is resolved (not be available in 1.2)

Best way to validate the jnlp is to launch the application and view the jnlp in Java Cache Viewer. Ensure that all entries are reflected properly. Update check must be set to “background” and not“timeout”.

Well.. I never thought that one character (or lack of it) can contribute so much towards start-up time! Keep exploring!!

When the page is loaded, the system time is noted using JavaScript. Time is again noted once Applet is loaded. Difference between time obtained in Applet and JavaScript is computed to be startup time. I think this will be fair and consistent way to measure startup time. This requires JavaSE 6 Update 10 and above. It will be good to try out a few times and get the average number..

Without JavaFX Runtime – After clearing Java Web Start cache – [ javaws -uninstall ] May have to wait for sometime as clearing process may be running in background. This is the time taken to download JavaFX runtime and load the applet.

It will be nice if we could break down the application into smaller modules and load the modules as and when its required. This will significantly reduce the start-up time. Here is an attempt to perform lazy loading of javafx modules.

A list of samples is shown. User can select the sample to be loaded from this list. The samples are dynamically loaded from JavaFX Samples. The sample is loaded using URLClassLoader. Then its instantiated and content of stage (JFrame) is obtained and added to main application.

Click on above image to load the Applet

This is an experimental implementation, just to try out the approach. There are issues with focus (cursor not shown on TextBox, but can still type), multiple Stage (JFrame) and may be some memory leak. The content is initially shown on another frame. Then its removed from original frame and added it to main frame. This causes some flickering. The implementation can be enhanced a bit so as to use some internal APIs and make things a bit more elegant. In any case I think the next version of JavaFX will have built in support for this. Which will be much more stable and flexible.

Disclaimer: Its an experimental implementation. Not concrete yet. Yes it can be enhanced. I just thought of putting it out so others can try to enhance it..

JavaFX “bind” and “on replace” are really nice and useful features. But recently I came across many misuse of this feature which results in performance issues. Here we will look into couple of common usage which leads to performance issues..

An example application is shown below…

For Applet mode, click on above image

For standalone mode

Example: In below code, the user wants to perform “update” operation when ever there is any change in x, y, w and height. The initial values of these variables are set to 0. Later as and when the application is shown on screen, actual values of these are updated.

But during this process, the “update” method is invoked 8 times! 4 times when the variable is initialized to 0 and another 4 times when the actual value is set. Instead if we perform a simple check to ensure that all variables are set before update, we could have easily avoided performing the complex operation so many times and improve performance.

But this will end up performing the operation many many times before the actual value required by user is set. Also the slider won’t be responsive, since we are constantly repeating the task. So instead of performing operation for each and every value with in the interval, we may just wait for few milli-seconds before performing the actual operation.

In above code a Timeline is started when ever the user changes the slider value. The actual operation is performed only after few (50ms in above code) milli-seconds. This will ensure that we won’t perform complex operation until user settles for a value.