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 <[email protected]> To: [email protected] 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.
