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.elias...@medsa.se> 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 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.rushfo...@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
