Re: JavaFX graphics performance

2017-04-18 Thread 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 
To: openjfx-dev@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.


Re: JavaFX graphics performance

2017-04-11 Thread Nikos Nikolos
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 
To: openjfx-dev@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 

JavaFX and OpenGL

2016-12-08 Thread Nikos Nikolos
Hello all,



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