JavaFX graphics performance

Nikos Nikolos nikos132 at
Tue Apr 11 13:26:52 UTC 2017

Here is a copy of a previous post I sent, needs are still the same on my
side and I don't see anything coming from the JavaFX side...

OpenGL rendering was a nice solution for performance intensive application
on the desktop. Since JavaFX doesn't offer a native OpenGL handle you can
use such a solution.

CSS and layout improvement are quite out of scope for the inital needs I

Electron is becoming trendy maybe with some WebGL inside it you will be
able to outperform JavaFX rendering speed!

I really enjoyed desktop GUI development in Java but them came JavaFX...

Following the thread
pipermail/openjfx-dev/2016-December/020025.html I would like to ask for
more information on JavaFX plan to allow a simple way to use existing
OpenGL code.

I know this is not a new question and please forgive me if I’ve overlooked
some answers already posted.

I work in the niche area where desktop applications are still needed and
use Swing since 2001, integrated Jogl and then Jogamp since 2006 and that
try to figure out how we can use JavaFX without a huge performance drop. I
think this bug is the best
summary of potential needs. And the answer gave by Kevin Rushforth was
quite disappointing.

I remember Swing teams members (Kenneth Bradley Russell) working hard to
have a nice way to use OpenGL in a platform independent manner which is one
of the strength of Java. JOGAMP team also made a good work more recently.

Some tricks have been used to try to provide a solution:




But they are very fragile (use of internal classes, rebundling JavaFx

Is this need too specific for a change to have it implemented in JavaFX?

Going on with Swing is a potential solution but it won’t resist a
comparison with QT long.

Thanks for any of your ideas on that.


---------- Message transféré ----------
From: Mattias Eliasson <mattias.eliasson at>
To: openjfx-dev at
Date: Tue, 11 Apr 2017 14:49:10 +0200
Subject: Re: JavaFX graphics performance
Excessive memory usage is more of a well documented JDK problem that
impacts the performance of many applications. Especially when having a
large collection of instances of the same class. In C++ an array of objects
are in memory similar to an array of structs. In Java they are arrays of
pointers to objects on the heap.

This could of course be worked around by storing data in arrays and using
classes to wrap those arrays. In one project I stored X and Y coordinates
in an array. I had a class with getter and setters but also with a
reference to the array and index. On top of that I had what worked
similarly to a standard object pool but in fact only had a few instances of
the object, changing index of a free object rather than allocating a new.
For simplicity I used an array for X and another for Y.

This pattern can be refined to align data in various ways for better cache
performance. And in our case there may be alignments that gives better GPU
performance. After all it's usually the GPU that process our data.

Of course it would be best if the JVM had better memory management
including something similar to a struct array without pointers to objects.
But there would still be need to have refinements. For example is it better
to have XXXYYY, XYXYXY, or perhaps YXYXYX? That in turn depends on cache
infrastructure, the order data is accessed and other factors.

In order notes the main competition to JavaFX is other Java APIs such as
Swing and it's Java2D. When it comes to performance we obviously have a
clear winner. But JavaFX isn't shipped within major Linux distributions so
it is yet considered experimental by many that use Swing. There are also
competition from SWT used by Eclipse and Azureus/Vuze. Packaging is one
problem but there are also UI components missing. The SWT on JavaFX
implementation has a list of SWT components and their JavaFX counterpart.
That list illustrates that there are a lot of work to do.

Of course once SWT on JavaFX is complete SWT will be eliminated as
competition. Especially if Eclipse use JavaFX as its SWT backend. It would
also mean that JavaFX is better equipped to compete with Swing as SWT
already is a strong competitor to Swing.

However SWT has been held back due to stability problems which probably
will not be in the way when it's based on JavaFX which is good enterprise

As for competing with web technologies it would have helped if we had a
modern browser plugin. JavaFX as an UI may not be faster than browser
technologies. But Java bytecode is a lot faster than JavaScript. Take RPC
for example. If you use browser technology you would probably be using Json
at best. With Java you have binary protocols like Jboss Remoting which ia
easy to code and much faster than using Json in JavaScript.

Web technologies can only compete where there is an API implemented in
something other than JavaScript. Once processing is done in JavaScript the
it becomes a lot slower than Java.

I would suggest creating a new fully sandboxed applet technology based on
JavaFX instead of AWT/Swing. That of course would be incompatible with
classic Applets but those are dead anyway. Make it at least as good as
Flash perhaps with an IDE like the commercial flash IDE. I mean
activescript vs Hotspot will not be a very fair match.

Another competitor is Unity and similar game engines. As unity is based on
mono and MonoDevelop we could do something similar using Java and eclipse.

When it comes to web/client server Vaadin has been gaining a lot of ground.
It's model of having a combined client and server code base using byte
buddy or ASM to separate client and server into separate executables is
impressive. I would like more control such as specifying @client or @server
in order to control where execution take place. But more to the point I
would like a JavaFX UI.

While web technologies are moving in on Java they do have a far way to go
before they have what java has. We have Hotspot for starters and that's way
ahead of JavaScript and Flash. What we don't have is browser integration.

Let's take the lessons learned from both Flash and Java Applets and make
something awesome. That doesn't carry "java" in the name. Like OpenFX? Or
"Arrow" (yeah I'm a nerd). This including the creative tools that Flash has
but perhaps also with features that Unity has.

Kevin Rushforth <kevin.rushforth at> skrev: (10 april 2017 22:08:04
>We are planning some performance improvements in JDK 10, mostly in the
>areas of CSS and layout. If you have specific concerns in other areas
>could look into them. Having a specific test case that shows a
>performance problem would be a good start.
>-- Kevin
>Michael Paus wrote:
>> Hi,
>> more and more people ask me why I am still doing GUI development in
>> JavaFX instead
>> of following the  mainstream and use some web technology. One of the
>> arguments
>> I could use in the past was performance but nowadays this does not
>> seem to be such
>> a valid argument anymore. Web technologies are catching up quickly
>> JavaFX currently
>> has not much to offer here. Actually the general drawing performance
>> is very bad compared
>> to what is in principle possible with a modern GPU. I even tried to
>> use a TriangleMesh
>> to better exploit the graphics hardware but this approach is also
>> limited by the fact that
>> a TrinangleMesh has an excessive memory usage (about 60 times its
>> nominal memory
>> consumption). I would therefore like to ask whether there are already
>> any plans for Java 10
>> to improve this situation?
>> Michael

More information about the openjfx-dev mailing list