JavaFX graphics performance

[Nikos Nikolos]

Thanks Mattias for your time on the subject.

I share some of your views on Qt and the complexity of data structures to
ensure best performance. But the Swing team did open the API to allow JOGL
first, now called JOGAMP to propose a nice binding to OpenGL. This way one
can use Java Swing and all its good parts to do the non performance
critical stuff and go with the low level binding of OpenGL to draw
performance intensive stuff.

Off course that meant direct buffers, native libraries and the risk to
crash the VM, but still staying in the "java realm".



I want to be able to reuse long crafted JOGL code in JavaFX but I can't
since it doesn't provide OpenGL context directly and using a JOGAMP
GLCanvas into a SwingNode is bit blit performance nightmare!

Considering a science application displaying 2D or 3D dynamic images with a
small amount of

I'll rather port my OpenGL code to fully OpenGL ES 3.0 and use web
technologies than  try to mess with JavaFX.

I'm quite disappointed by the fact that JavaFX doesn’t even consider this
need as relevant, that’s why I try to argue and understand. I can image
that these needs are too specific for the JavaFX team but I see it as a
leave for Oracle/Java to stay in the desktop GUI technology.



I am a user of Java Swing since 1999, used QT too, and was happy to go on
with Java so, once again, it make me sad…



Regards.
---------- Message transféré ----------
From: Mattias Eliasson <mattias.eliasson at medsa.se>
To: openjfx-dev at openjdk.java.net
Cc:
Bcc:
Date: Fri, 14 Apr 2017 15:04:20 +0200
Subject: Re: JavaFX graphics performance
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.