JavaFX 2.0 – First Impressions.

Posted by Steven Herod on Mar 6, 2011 in Uncategorized

A bit of history

I got involved with JavaFX the week of the 1.0 General Availability release in… November 2008?  That week I started work on Twitt3rFX, a JavaFX based Twitter client.  It was hard going with 1.0, performance was poor, tooling was poor, and the overall functionality of JavaFX was low, I needed to build my own scrolling views for instance, and spent a great deal of time trying to get performance acceptable.

I struggled on for nearly a year and by the time I effectively abandoned my effort I was convinced of two things.  One, I really need to re-write it :) and two, JavaFX 1.x wasn’t ready for primetime.  I was happy with a my own hobbiest efforts, but if my employer had looked me in the eye and said ‘Hey, we’re going to spend xx dollars basing our new platform on JavaFX’ I would have taken them to one side and tried to talk them out of it.

So, with that background… what do I think of the new JavaFX 2.0 EA?

First impressions of 2.0

This is the first release of the Java based version of JavaFX and  the abandonment of JavaFX Script, the programming language around which JavaFX based, and I must say, I think dumping the scripting language was a great idea.

Whilst JavaFX Script had some unique features – native support for closures for one, it definitely had its flaws.  Tooling support wasn’t anywhere near as sophisticated (or reliable) as the support Java has, you were tied to Netbeans – and there was little if any integration with Swing. Even integrating with normal Java libraries wasn’t perfect.

That all said, I think moving back to Java has been a great decision.  I’m currently working in IntelliJ community edition, and the power I get from a real IDE more than makes up for the loss of expressiveness in the language.

With one exception… the lack of closures in Java.  I’ve never written so many anonymous inner classes in my life :)

What’s in the box

My fear about JavaFX 2.0 was that it was going to reset functionality back to 1.0 levels (but in Java).  Luckily, this fear has been unfounded,  JavaFX is control (and layout) rich.  I’ve personally used Grid, VBox, Flow, Hbox layouts, and the Listview, Popup menu, Menu Button, Hyperlink, Text, Tree Pane, Tab Pane and the near mythical Web Pane (Which is a WebKit based Web view) and for the most part, they are working as intended.

I’d put a screenshot, but it looks god awful at the moment and not ready for public consumption.

I haven’t delved into animations, effects or CSS styling yet as I’ve been focusing on functionality and  application structure, but for an Early Access, I’m impressed with the work the JavaFX team has put in already, and I’m looking forward to following its progress over the coming months.



Links for JavaFX SJUG Talk

Posted by Steven Herod on Oct 8, 2009 in Uncategorized

Learn JavaFX


Video Code Support info



Third Party Components



Writing a JavaFX application that detects and blocks Twitter Spammers.

Posted by Steven Herod on Jul 21, 2009 in Uncategorized

Like alot of people I’ve been plagued by the vast number of spammers who follow you on twitter, either out and out spammers, or mis-guided ‘SEO’ and ‘Online Marketing’ people who seem to think that having a vast array of followers is the path to millions of dollars.

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.

login screenretreival of followersmain interface


JavaFX and Hardware Acceleration (Take 3)

Posted by Steven Herod on Jul 21, 2009 in Uncategorized

Firstly, forget everything I said in part 1 and part 2 of this series.

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)

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.
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)

You can run the final version here


JavaFX effects and hardware acceleration… (Take 2)

Posted by Steven Herod on Jul 21, 2009 in Uncategorized

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!


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

Thanks to all those that played along with sorting this out, especially Jonathan Giles for putting up with my ‘could you try again’ requests and Richard Osbaldeston (who is available for hire!) for spotting my JNLP stuff up.


JavaFX effects and hardware acceleration…

Posted by Steven Herod on Jul 20, 2009 in Uncategorized

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.

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()



TwitterFX – What next?

Posted by Steven Herod on Jul 8, 2009 in twitterfx

Work begain on TwitterFX the weekend after the public release of JavaFX 1.0 and has continued, through fits and starts up until today.

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).


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)


Animated GIF’s in JavaFX, a word of warning…

Posted by Steven Herod on Jun 28, 2009 in twitterfx

I’ve learned many things over the course of putting together TwitterFX, and for the most part, I’ve failed to share them with the world!

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.

Tags: ,


TwitterFX: New dev version out (0.20b)

Posted by Steven Herod on Jan 28, 2009 in twitterfx

It can be access here:  http://herod.net/twitterfxdev/TwitterFX.jnlp

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!


First Post!

Posted by Steven Herod on Jan 25, 2009 in Uncategorized

Well, its time to start blogging about my JavaFX experiences. I’m sure the world is waiting with baited breath!


Copyright © 2015 Fumbling Forward All rights reserved. Theme by Laptop Geek.