Planning for JavaFX.next

[Erik De Rijcke]

On of the major problems we have here using javafx is the the extremely
slow loading speed of the fxmls (we have about 15000+ arm cortex devices
running javafx in production). Sure, there is a lot to gain in manually
optimizing and reducing the number of nodes and whatnot, but that kinda
beats the purpose of having fast development cycle using jfx. As an
experiment we used a rather unkown/obscure fxml precompiler and noticed a
speed gain of 10s (worst case fxml) -> 0.1s!

My proposal is thus to absolutely have an fxml precompiler as the speed
gains are tremendous on slower devices.

Further I would +1 the CSS performance.

Another major hurdle we had was the complete inability to inter-operate
with any native hw acceleration (OpenGL ES2 to render a GPS navigator
inside the jfx app to be precise). Sure I understand the need to abstract
things away given that the user/programmer should not notice what platform
he's running on. In reality it is often very well known which platform will
be used. It would be nice to at least have some handles (through JNI?) to
use the existng jfx rendering context and issue your own custom gl
commands. Now we ended up rendering in a separate context and doing a
glreadpixels, copy that to the java/jfx side and render to an image.
Needless to say the performance is shi^H^H^H not good.

In general would say to have a look at your main competitor (Qt-gui imho),
see what jfx does well and make sure it keeps doing that, and see what
Qt-gui does better (speed, qml, native api exposure, wayland support to
name a few)  and improve upon that.

2016-12-08 10:22 GMT+01:00 Dirk Lemmermann <dlemmermann at gmail.com>:

> I have these priorities regarding the items mentioned by Jonathan:
>
> “Put the pedal to the metal” section:
>   +1 CSS performance improvements
>   +1 TableView performance
>   +1 Marlin renderer enabled by default
>
> “The rest” section:
>   +1 TableView improvements (cell spanning, row / column freezing, etc)
>   +1 Focus traversal API
>   +1 A JavaFX equivalent of the AWT Desktop APIs
>
> —Dirk
>
> http://www.dlsc.com