Learn JavaFX

• Core Language Tutorial
• JavaFX.com
• Amy Fowler’s blog entry on layout
• Amy Fowler’s blog on layoutBounds

Books

• Pro JavaFX

Video Code Support info

• Media in JavaFX

Blogs

• FX Experience
• JFXstudio
• Dean Iverson’s Blog
• James Weaver’s Blog
• Jonathan Giles’s Blog (Java Desktop Links of the Week)

TwitterFX

• Project Kenai homepage
• Run Current Version

Third Party Components

• JFXtras

Tweeters

• JavaFX Twibe
• @javafx4you -> Official Sun marketing for JavaFX, retweets most JavaFX tweets.

The structure of Twitter means that their follows are mostly benign, but they do clutter up your follower list and of course inflate your follower count (I’d prefer to have 40 people hanging on my every word than 4000 fakes).

So this application, tentatively named ‘Spank’em’ (but in desperate need of a better name) is intended to use the Twitter API to retrieve your followers and then use heuristics to categorize each follower as good or evil. It will then allow you to do some manual tweaking and finally allow you to block the lot in a single click.

Sounds useful?  Oh, and it’s going to be built in JavaFX, using the new Twitter API implementation I’m slowly working on and contributing (hopefully) to the JFxtra’s project. (Basically it lets me work through in improving the API with a real app, but without all the complexity of TwitterFX.

If I maintain the motivation, I’m going to blog my way through the creation of the application. This hopes to inform folk learning JavaFX, and hopefully attract the attention of others who can give me suggestions for improved approaches…

Below are some mockups of what the UI might look like, feedback appreciated.

I’m serious.

Mind clear?

Right, lets begin again.

Judging by what I’ve learned over the last two days I should really be calling this blog enter ‘getAccelType() and its idiosyncracies‘, not ‘JavaFX and Hardware acceleration‘.

The first thing you need to know is that JavaFX will use your machines GPU capabilities if they exist.

The second thing you need to know is that getAccelType() may not report the correct answers unless you take some explicit steps to ensure that occurs.

Here is a summary

What does getAccelType() do?

From the javafxoc: Returns a String representing the type of hardware acceleration, if any, that is used when applying this Effect on the given GraphicsConfiguration.

It would appear to return 1 of 5 of values for each effect

• OpenGL (Mac)
  Seen on MacBook Pro’s with the appropriate video cards
• Direct3D (Windows)
  Windows only, widely seen on Windows platform
• CPU/SIMD (Any platform)
  Believed that it uses the SSE (or like) extensions on your CPU, this is the method seen on MacBook’s with Intel video cards
• CPU/Java (Any platform)
  Meaning of this one isn’t immediately apparent, but its been observed on Linux platforms
• Intrinsic (Any platform)
  “Intrinsic just means the “platform” handles the filtering operation. For instance Reflection is implemented using Java2D operations, no shaders, no special software loops, so it’s marked “intrinsic” ”
  

When should you use it?

Never.  Probably.  Chris Campbell from Sun remarked “people aren’t supposed to know about getAccelType()”.

I suppose it could be useful if you specifically wanted to test for Direct3D or OpenGL prior to adding lots of effects, but I would strongly suggest you do some benchmarking first to see if its going to make a difference… (See below)

How should I use it?

Well, you probably shouldn’t, but now that you’ve decided you need to use it, here is the caveat you need to know.

You need to make any decision about hardware capabilities you are running on at the appropriate point in time in your application, otherwise you are going to get the wrong answer (it will erroneously return CPU/SIMD not the Direct3D you should get under Windows).  Note this erroneous answer has no relationship to what JavaFX will actually use, for instance, you may get the return value of ‘CPU/SIMD’ and then JavaFX will happily go on and use Direct3D.

When is this time?  Well, its either ‘at any time’ in a signed Webstart app with the appropriate security permissions, or at the ‘right time’ in an unsigned webstart application.  When is the he right time you ask?

Dmitri Trembovetski (from Sun) notes this as:

“Note that this (ed: requirement for signing) becomes an issue only if the application explicitly initializes effect’s peers by calling Effect.getAccelType() before the runtime has a chance to do so.”

This means you need to call your effects tests AFTER the runtime has done its full initialization, in Dimitri’s example, he does this the use of FX.deferAction after the creation of the Stage
FX.deferAction(function():Void {
accel = for (effect in effects)
“{effect.getClass().getSimpleName()}.getAccelType(gc)={effect.getAccelType(gc)}”;
});

Final points

This need for signing, or testing and the right time is probably going to change in the future, as we said in part 2, a bug has been raised and indications are it will be corrected but as the man reportedly said, premature optimization is the root of all evil so my advice, just get busy writing apps and don’t try and outfox the runtime with conditional effects.

Below is the full sourcecode of Leadfoot as of today, this will run in an unsigned Webstart app.  This is effectively Dimitri’s code now, so… um thanks I owe you a beer (or vodka or orange juice).


/*

package leadfoot;

import javafx.scene.Scene;
import javafx.scene.control.ListView;
import javafx.scene.effect.*;
import javafx.stage.Stage;
import java.awt.GraphicsEnvironment;
import javafx.scene.shape.Rectangle;

def gc = GraphicsEnvironment.
getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
def effects = [
Blend {}
Bloom {}
BoxBlur {}
ColorAdjust {}
DisplacementMap {}
DropShadow {}
Flood {}
GaussianBlur {}
Glow {}
Identity {}
InnerShadow {}
InvertMask {}
Lighting {}
MotionBlur {}
PerspectiveTransform {}
Reflection {}
SepiaTone {}
Shadow {}
];
var accel : String[];

Stage {
scene: Scene {
content: [
Rectangle { width: 10 height: 10 effect: GaussianBlur {} }
ListView {
width: 350
items: bind accel
}
]
}
}
FX.deferAction(function():Void {
accel = for (effect in effects)
“{effect.getClass().getSimpleName()}.getAccelType(gc)={effect.getAccelType(gc)}”;
});

You can run the final version here

Note, this entry has been superceeded by Take 3, you can read it for historical context/further explanation, but you should forget its conclusion, JavaFX webstart apps DO NOT require signing to use Direct3D.

Well, there is a reason I call this blog Fumbling Forward.

So, its been an interesting day.  It wasn’t very long after posting my blog entry that I started getting feedback from people, mainly a growing sense of mild alarm related to the answers people were receiving from running the application.

It seemed a far too many people were getting the CPU/SIMD answer when they were expecting Direct3d.

Thus, the investigation began!  First there was the bug I had in my app in the way I was passing GraphicsConfiguration to the effects, but after that was fixed, still no joy.

Well, there was some joy, thos running code locally were getting the right answers, but from the website – nothing.

It turned out the problem was related solely to Webstart versions of Leadfoot.

Stephen Chin (jfxtra’s dude and erstwhile author) eventually tracked the problem down, it seems that Direct 3D is only enabled if you run your application from Webstart as a signed application, and specifically, request the appropriate security permissions.  Stephen has raised defect RT-5193 at javafx-jira.kenai.com

So, you can start the new version which is self signed, and with the appropriate security tags in the JNLP.   Let me know how you go!

Summary

Webstart JavaFX apps require signing and the appropriate <security> tags in your JNLP file. NO, they don’t!

Note, this entry has been superceeded by Take 3, you can read it for historical context/further explanation.  The comments of this blog are also of value as they lead to what I’ve restated in ‘Take 3′

This post was sparked today by Jonathan Giles and his optimization of Josh Marinacci’s particle accelerator demo.

One of the questions I asked after he posted his blog entry was “Do you know if hardware acceleration being used for your effects?”

He didn’t know, and to be honest, I wasn’t entirely sure how to check myself.

So, I whipped up this test called Leadfoot (because it’s all about Acceleration

It’s a JavaFX 1.2 app, and you can run it using webstart by clicking here.

Here are some of the answers so far:

What does it all mean? Well, “CPU/SIMD” apparently is hardware acceleration. I’m still not entirely sure! I believe CPU/SIMD relates to the fact it is using the SSE instructions on the CPU. Which is NOT by my definition, the GPU on your video card. So the question remains, under what circumstances does GPU aceleration actually occur?

More news: Other users have reported OpenGL (On a MacBook Pro, see gallery) and CPU/Java (On Ubuntu and on Windows with an older Toshiba laptop)

Below is the source code, feedback welcome!


/*
* Main.fx
*
* Created on Jul 20, 2009, 8:38:21 PM
*/

package leadfoot;

import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.control.ListView;

import javafx.scene.effect.Blend;

import java.awt.GraphicsConfiguration;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import javafx.scene.effect.Bloom;
import javafx.scene.effect.ColorAdjust;
import javafx.scene.effect.DisplacementMap;
import javafx.scene.effect.DropShadow;
import javafx.scene.effect.Flood;
import javafx.scene.effect.GaussianBlur;
import javafx.scene.effect.Glow;
import javafx.scene.effect.Identity;
import javafx.scene.effect.InnerShadow;
import javafx.scene.effect.InvertMask;
import javafx.scene.effect.Lighting;
import javafx.scene.effect.MotionBlur;
import javafx.scene.effect.PerspectiveTransform;
import javafx.scene.effect.Reflection;
import javafx.scene.effect.SepiaTone;
import javafx.scene.effect.Shadow;

import javafx.scene.effect.BoxBlur;

/**
* @author steven
*/

function getAccelerationFaults():Object[] {

def gc = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();

var returnVal:Object[];

var blend:Blend = new Blend();
insert “blend: {blend.getAccelType(gc)}” into returnVal;

var bloom:Bloom = new Bloom();
insert “bloom: {bloom.getAccelType(gc)}” into returnVal;

var boxBlur:BoxBlur = new BoxBlur();
insert “boxBlur: {boxBlur.getAccelType(gc)}” into returnVal;

var colorAdjust:ColorAdjust = new ColorAdjust();
insert “colorAdjust: {colorAdjust.getAccelType(gc)}” into returnVal;

var displacmentMap:DisplacementMap = new DisplacementMap();
insert “displacmentMap: {displacmentMap.getAccelType(gc)}” into returnVal;

var dropShadow:DropShadow = new DropShadow();
insert “dropShadow: {dropShadow.getAccelType(gc)}” into returnVal;

var flood:Flood = new Flood();
insert “flood: {flood.getAccelType(gc)}” into returnVal;

var gaussianBlur:GaussianBlur = new GaussianBlur();
insert “gaussianBlur: {gaussianBlur.getAccelType(gc)}” into returnVal;

var glow:Glow = new Glow();
insert “glow: {glow.getAccelType(gc)}” into returnVal;

var identity:Identity = new Identity();
insert “identity: {identity.getAccelType(gc)}” into returnVal;

var innerShadow:InnerShadow = new InnerShadow();
insert “innerShadow: {innerShadow.getAccelType(gc)}” into returnVal;

var invertMask:InvertMask = new InvertMask();
insert “invertMask: {invertMask.getAccelType(gc)}” into returnVal;

var lighting:Lighting = new Lighting();
insert “lighting: {lighting.getAccelType(gc)}” into returnVal;

var motionBlur:MotionBlur = new MotionBlur();
insert “motionBlur: {motionBlur.getAccelType(gc)}” into returnVal;

var perspectiveTransform:PerspectiveTransform = new PerspectiveTransform();
insert “perspectiveTransform: {perspectiveTransform.getAccelType(gc)}” into returnVal;

var reflection:Reflection = new Reflection();
insert “reflection: {reflection.getAccelType(gc)}” into returnVal;

var sepiaTone:SepiaTone = new SepiaTone();
insert “sepiaTone: {sepiaTone.getAccelType(gc)}” into returnVal;

var shadow:Shadow = new Shadow();
insert “shadow: {shadow.getAccelType(gc)}” into returnVal;

return returnVal;
}

Stage {
title: “Leadfoot”
width: 250
height: 400
scene: Scene {
content: [
ListView {
width: 250
items: getAccelerationFaults()
}

]
}
}


Currently, it is a reasonably feature complete Twitter client based on JavaFX 1.1 and the question I have been asking myself is, where to from here?

As it stands today, the major outstanding activity is to port the application to JavaFX 1.2 and to use the native controls and new features released in the latest version.

Basic work has been undertaken to accomplish this work, there is a moderate amount of effort to get the application back to the point of running again, but further work is required to refactor code which relies on Java 1.1 features which have had their underlying API’s modified.

This is not terribly complicated, but I’m reluctant to do a straight port of the application and instead want to invest my time and effort in reassessing the goals of TwitterFX.

As it stands today there are a couple of possible thoughts which are not at all mutually exclusive. What I’d like to do is throw it open to the user base for comment and feedback.

Thought One – Split out the Twitter API code into a separate project.

I think its of value to have a separately evolving project which offers a JavaFX interface to the Twitter API, and that this library be able to be freely included in other projects which may need to communicate to Twitter.

Thought Two – Use TwitterFX as a reference JavaFX application

Consider if TwitterFX is stripped back to the functionality only available in the JavaFX Common/Desktop/Mobile profiles. Work can then be mainly on the internals and use the application as a ‘reference’ for building a medium sized app in JavaFX that targets mobile and desktop (and potentially TV).

Thought Three – Rework the internals for clarity and performance

Currently the under the covers impl of TwitterFX is in my opinion, somewhat haphazard which is making maintenance harder than it should be. There is also a significant amount of static initialization, which is why start up is relatively slow and why its initial memory footprint is higher than it could be.

Thought Four – Simple vs Complex

Much of the progression of TwitterFX was driven by attempts to become feature comparable with TweetDeck on the basis of it being the most popular and feature rich Twitter client. However, Desktop Tweetie (Mac only) was released during the development of TwitterFX and it became apparent to me that there is another, just as significant group of users – those who like something which is functionally limited, but is elegantly implemented.

To a certain extent the advanced mode/simple mode toggle did for a while cater for this, but I remain convinced as to if I am fully satisfying either audience.

For instance, Thought Two (A reference JavaFX application) would by definition result in a much simpler application, however other people have suggested it could also become a full social networking client, like a Seismic Desktop or Digsby.

Thought Five – Show me the money

Would you pay for this thing? Discuss.
(I have a Wife and Child who would quite like Daddy to have something show for all the nights and weekends he works on this thing).

Conclusion

Anyway, I wanted to throw this out there to let people know where my mind is at and have them opt in.

PS TwitterFX is now licensed under BSD (It’s no longer GPL 2)

I hope to change this over the coming weeks/months, but in the meantime, here is a tidbit.

One of neat things about JavaFX is the ease with which one can place Image and ImageView elements into your applicaton.

Not only does JavaFX support feedback on image loading and powerful effects, it will automatically render any GIF animation.

There is a however a caveat! Animated GIFs

JavaFX provides no way (that I can tell) to detect if an image is an animated GIF, or to control said GIF (for instance, to stop the animation)

Furthermore, the rendering of animated GIFs in JavaFX seems to be quite inefficient at this time and if you think you are going to add animation to your application easily by dropping in an animated GIF I wouldn’t recommend it.

In my experience, you can expect placing an animated GIF in your UI will cause your application to consume around 20% + more of CPU time on a Core 2 Duo! This may occur even if the image is hidden, but ceases after the image is removed from the scene graph.

Native JavaFX Timelines or the two Progress Indicator classes ProgressIndicator and ProgressBar l are a more efficient and powerful way of providing progress indicators or animation.

It includes

• Fix for counts on new tweets since scrolling changes
• Fix for duplicate new tweets since scrolling changes
• Now announces itself to Twitter as a proper client (Tells the world you are using TwitterFX)
• Switched to using https:// instead of http:// for all conversations with Twitter

I’m behind on a new ‘proper’ version, I just don’t want to officially release anything thats too dodgy!