JavaFX graphics performance and suitability for advanced animations

John C. Turnbull ozemale at
Fri May 31 05:30:17 PDT 2013

Hi Richard,

Let me start by saying that on re-reading my last post I realised that it
had a "tone" which was not intended and may have appeared overly critical or
negative.  If you or anyone on the JavaFX development team were offended in
any way then I am sorry.  All I can say in my defence was that it was posted
after midnight at the end of a very long day...

Anyway, I want you to know that I am not here to engage in gratuitous JavaFX
bashing or trolling.  In fact, I am one of the strongest supporters and
proponents of JavaFX that there is.  I am in the process of bringing JavaFX
into my (large corporate) workplace and am involved in a private project
which I take very seriously that will also be using JavaFX.  Consequently I
have more at stake and more interest in having JavaFX succeed than most.  If
everything goes according to "plan", I will be focussing on Java and
especially JavaFX for the next 10 years or so.

>From my perspective it is important to address the features or issues with
JavaFX that the competitors perceive as weaknesses and reasons why the
technology is a "dead duck".  The JavaFX community is vibrant with many
well-known evangelists who are doing a very good job of promoting JavaFX and
highlighting its many benefits but it is rare for them to say anything
negative about it.

Is this because there are no "negatives" with JavaFX or is just that they
steer clear of them?  I tend to think that they prefer to concentrate on the
pros rather than the cons and that's fair enough, they are there to further
the cause of JavaFX rather than detract from it.

I am someone who has been told tends to "say the things that other people
think but are afraid to say".  I am not out to  win any popularity contests
and will call a spade a spade.  As I said, when it comes to JavaFX, I am
doing this because we need a balanced argument that confronts the opposition
head on.  Many of the criticisms levelled at JavaFX by competitors have a
valid foundation and as community we need to be able to respond to them.
The issues I highlighted in my last post are real and I very much believe
that if solutions are not found then JavaFX is going to struggle in the
"real world" in the longer term.

The market for graphics toolkits and cross-platform developer tools is
extremely competitive and cut-throat and no one is going to give JavaFX a
break.  I am merely trying to bring these issues up within the JavaFX
community so we can address them as soon as possible.  As I said, I am very
much *for* JavaFX.  I both want it to succeed and *need* it to succeed.

As Daniel Zwolenski has posted, animations which I have found to perform
quite poorly in JavaFX work very well inside a web page with JavaScript
(with or without Canvas) on the exact same machine.  Clearly then there must
be something fundamentally different in the way these competing technologies
are handling animations.  To me this says that it must be possible for
JavaFX to achieve similar levels of performance as other technologies are
able to extract better performance out of the same OS and hardware.

This says to me that developers who are not necessarily tied to the Java
language for any reason would obviously choose a technology that performs
better.  This is the concern.  This is the kind of thing we need to redress.

Whilst my comments may be seen to be unnecessarily critical, I am being far
kinder than our competitors.  New features can be added to JavaFX but if the
"core" features are not working as well as the other products on the market
then clearly there is a real problem.

I made a comment along the lines that I feel the animations in the Ensemble
demos do very little to promote JavaFX and, as harsh as it may sound, I
stand by that.  Scott Palmer has echoed those sentiments with his recent
commentary on Brick Breaker.  While obviously it's a lot of work, JavaFX
needs at least one truly awesome demo that showcases everything it has to
offer.  If such a demo is not possible with JavaFX as it currently stands
then that tells us something.

My own personal feelings about JavaFX are that it is an absolutely awesome
product with amazing potential.  It is a vast improvement over Swing and,
although not many people outside the Java community realise this, it has
features and capabilities that other competing products simply don't have.
If we can get the basics working better, JavaFX has the potential to be a
very significant player and not just for developers who have traditionally
programmed in Java.  For me, they are the people we should really be

Also, I think the JavaFX development team are doing a first class job.  Even
though I think I made this clear, none of my critical commentary is directed
at them.  I also acknowledge that my references to the policies of Oracle
management are not particularly helpful in this forum as clearly nothing I
say here is going to change anything in that respect.  Such comments
probably only serve to frustrate the development team even more than they
are already are.

So, in summary, I am here to help.  Whilst you may not agree with my
methods, please know that I have the best interests of JavaFX and the
community in mind.  I am prepared to do whatever it takes to ensure the
success of JavaFX on a vast variety of platforms and for as long as
possible.  I am going to devote some time into building OpenJFX and trying
to get to the bottom of the performance issues I have informally reported.

If other products can achieve high-quality and high-performance animations
on my computers then why can't JavaFX?  The answers must be out there...


-----Original Message-----
From: Richard Bair [mailto:richard.bair at] 
Sent: Friday, 31 May 2013 01:12
To: John C. Turnbull
Cc: openjfx-dev at
Subject: Re: JavaFX graphics performance and suitability for advanced

Hi John,

> Graphics?  Yes, to a point.  But my post was really about graphics and 
> the issues related to performance.  Again, unless those issues are 
> resolved then it's not appropriate to state that JavaFX is suitable for

You asked what the "full range of applications for which JavaFX is or will
be suitable for".

> Then you mention Halo 5.  I have to say the subtext here troubles me 
> greatly.  If I read you correctly then you are saying that JavaFX is 
> not really suitable for games (at least anything beyond the demands of 
> something like Solitaire).  As someone else pointed out, what is point 
> of developing 3D support in JavaFX if it is not really suitable for 
> games?  To say it is not suitable for games implies that it is not 
> really suitable for *any* application that requires performant 
> animations and visualisations.  What use then is the 3D API?

That's not fair at all. There are a *lot* of enterprise use cases for 3D,
and we get these requests all the time. Whether we're taking about 3D
visualizations for medical or engineering applications or consumer
applications (product display, etc), there is a requirement for 3D that are
broader than real time first person shooters.

Game engines often have very specialized scene graphs (sometimes several of
them) as well as very specialized tricks for getting the most out of their
graphics cards. When we expose API that allows people to hammer the card
directly, then it would be possible for somebody to build some of the UI in
FX and let their game engine be hand written (in Unity or JOGL or whatever).

>>> 4.       Is JavaFX more targeted at form-based UIs rather than high
>>> performance graphics?
>> No.
> Again, good to know but where are all the high-performance JavaFX 
> apps?  So far I have seen nothing but form-based apps.  Wouldn't it be 
> prudent for Oracle to include a "showcase" app or game that shows us 
> the full capabilities of JavaFX with high-performance graphics?
> I am sure I am not alone in feeling that the animation examples in 
> Ensemble do very little to promote the graphics capabilities of JavaFX.

Are you offering to contribute? :-)

>> Are your slow examples reproducible? If so we need the test case. Is 
>> there
> an issue filed? We can't fix things we can't reproduce.
>> We spend a *considerable* amount of time and energy on performance 
>> and for
> the things we're measuring we're doing well.
>> As the saying goes "what's measured, improves". After the switch to 
>> gradle
> and the new project layout, one thing I'm going to
>> look at is using JMH[2] in OpenJFX so we can write micro benchmarks 
>> and
> have them easy for everybody to run and
>> contribute to. Our current set of micro benchmarks are based on the
> predecessor of JMH which was the
>> JRockit benchmark suite and was proprietary (hence we cannot just 
>> open
> source our existing benchmarks without doing some rewrite).
> All good points.
> However, I am not sure that having me preparing "reproducible" test 
> cases will actually help.  In my experience, the Ensemble app already 
> serves this purpose.  The choppiness I describe is *always* prevalent 
> when I run the animations and transitions in Ensemble (including 
> Ensemble 8).  The only variation is in the degree of that choppiness.

Then start with that, something absolutely dead simple like a path animation
or rotate transition and lets figure out how to measure the jitter and get
it into our benchmark suite.


More information about the openjfx-dev mailing list