We have been developing for 6 moths a very critical system (realtime control system). Our results are being very promising and JavaFX is great. Our system is very big and complex:
  - Desktop application
  - Scenegraph with more of 40.000 nodes.
  - Very high time response needs.
  - Huge screen resolution (3840x2160).

  By the moment we have developed an incredible HMI, with maps (GIS), tabulars, menus, touch displays, animations... but we have a problem that we doesn't know how to approach.

  The situation is that we must do a very heavy update of many objects in the scene (mainly only a translation) every second, up to 1500 simple panels over the map (represent real mobile objects). And it works well. But the problem is that when this periodic update (one time in a second) is performed, all the animations are frozen. This is a big problem for us, because for the user it seems that the system is not stable. When the user interacts with the application, suffers pausing and accelerating.

  We understand the reason for this, because we have studied deeply the quantum strategy. And we have tried many, many things:
    - We have simplified the Scenegraph.
    - We have optimized the nodes, we don't use Paths, nor Polylines, nor transparencies.
    - We use eficiently the JavaFX cache, to help JavaFX in the render process.
    - We purge all the nodes (visible to false) that are not in the visible screen.
    - Depending on the zoom, we simplify (reduce the number of lines) of the maps to the minimum.
    ....

  And the performance has increased significantly, but it is not enough. The periodically frozen effect is very ugly.

  We think there are two ways to improve this:

  A.- JavaFX must improve the parallelism in the render process. Now is too serialized (bottleneck). We have 16 cores in the production machines!!! And only one core is working up to 100%, and the others are not used at all. There are plans to improve this in the future?

  B.- Breakup the rendering for the background objects (very heavy) and the interaction ones (very light):
    We have tried several strategies, with no luck:
      - Prioritize each kind of update. The Quantum is God, and all it's done at the same time. No way to prioritize animations, or updates.
      - Instancing two JavaFX engines: JavaFX is singleton and it is impossible.
      - Pipelining the heavy updates (little by little): The result is worst, because each incremental change in the map is almost expensive that the complete update.
      - Doing two OS process (one for the slow and heavy background, and other for the light and fast interaction objects). Yes it is a crazy aproach, but we are desesperate!:
         * One on the back, and the other at the top, with a transparent stage. In Linux the performance of transparent stages is horrible. So the result is worst.
         * One process renders to an image the background, and sends it to the first that uses it as an prerendered image. This is the only promising way we have tried, but the performance it's no so good, not to mention how to solve the event propagation between the processes (because the background processes are clickable, draggable...).


  Any more ideas? And what about more parallelism in the Quatum processing?

  Thanks a lot for your incredible work with JavaFX,and every week we are waiting impatiently the each new release,
     Fernando