JavaFX graphics performance

Fri Apr 14 13:04:20 UTC 2017

If what you want is the best performance than neither JavaFX nor web technologies will do. Qt as you mentioned will be much faster and it has native support for embedding OpenGL. In addition you can combine Qt with native optimizations for specific platforms. You can even add inline assembly in order to do very specific optimizations. Hand optimized assembly by a skilled developer will never be outperformed by anything else. The problem with these things of course is that they add a lot of work. Writing Qt code requires you to handle memory and threads and I can constantly see Qt developers failing at this. The VLC UI is written in Qt and it spits out a decent amount of Qt errors on the conseole, and that is probably one of the most well written Qt applications. We have the entire KDE ecosystem based on Qt which is infamous for it's many bugs. And assembly programming of course is a lot more problematic. In order to outperform pre-existing system libraries you sometimes need to know undocumented instructions used by system libraries. This is less of a problem today than it was 20 years ago but it still takes a lot to be good at assembly programming.

However this is the JavaFX mailing list so in order to stay on topic I think the discussion should be about how to improve JavaFX performance. Some problems of course are related to the JavaFX code itself, others are rooted in the Java architecture and in JVM memory management. The fact that doing something similar to C/C++ structs and "pragma align" requires ninja level trickery is a problem. I don't know if this is a problem for OpenGL but sometimes when integrating with external systems the lack of "unsigned" is also a real problem, it's probably not a performance problem but writing correct code that deals with data containing unisgned integers can be quite a mess. I don't know OpenGL data structures well enough but in many Internet protocols there are lots of unsigened data to be processed. Also many file formats has that problem.

When we are trying to interface Java with low level data such as OpenGL data structures we must recognise that we may need to take these things into consideration for upcoming versions of the JVM. One problem of course are how to deal with these kind of data structures while preserving data integrity and the Java way of doing bounds checking. This is also a big issue I have with the current hacks one have to perform in order to deal with data structures, dealing with large arrays moves the responsibility of data integrity to the application which of course is a breeding ground for bugs.

On Tue, 11 Apr 2017 15:26:52 +0200
Nikos Nikolos <nikos132 at gmail.com> wrote:

> 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
> think.
> 
> 
> 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 http://mail.openjdk.java.net/
> 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 https://bugs.openjdk.java.net/browse/JDK-8091324 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:
> 
> ·         https://github.com/SkyLandTW/JOGL-FX#jogl-on-javafx-es2
> 
> ·         https://github.com/pepe1914/jfx-zoglpipeline
> 
> ·         https://www.youtube.com/watch?v=aYRF34UYu-E
> 
> But they are very fragile (use of internal classes, rebundling JavaFx
> jars…).
> 
> 
> 
> 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.
> 
> Regards
> 
> 
> 
> ---------- Message transféré ----------
> From: Mattias Eliasson <mattias.eliasson at medsa.se>
> To: openjfx-dev at openjdk.java.net
> Cc:
> Bcc:
> 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
> code.
> 
> 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 oracle.com> skrev: (10 april 2017 22:08:04
> CEST)
> >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
> >we
> >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
> >and
> >> 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

-- 
Mattias Eliasson <mattias.eliasson at medsa.se>