Cheers for the link.
Separate threads for rendering and key events, yay!
Pity that the post didn’t go into details about the rendering back end prism and how it works.
[quote]Concurrent Rendering
The first thing you will notice in JavaFX 2 is that it does event handling and rendering in different threads. And you will notice that… drum roll… because it will likely break your code – either legacy code ported from JavaFX 1, or new code written with old habits in mind, from Swing or other single-threaded UI toolkits or game engines. It certainly broke my initial port of JavaFX Balls (see next section). The JavaFX 2 runtime manages two threads:
* The EDT (event dispatch thread), identified as the “JavaFX Application Thread”. That’s where all your app code runs by default, including animation events (Timeline action handlers) or any other events.
* The Renderer thread, identified as “QuantumRenderer”. That’s where your scene graph is transformed, composed, rasterized etc., until you get nice pixels in the screen.
* The Media thread, identified as “JFXMedia Player EventQueueThread”. This takes care of video and sound playback tasks, such as decoding and buffering.
This is a powerful architecture; multicore CPUs are now the rule even in high-end mobile devices, so if your app leaves at least one core free, you get rendering “for free”. JavaFX’s Prism toolkit is fully GPU-accelerated, but the concurrent renderer is still important, because JavaFX’s rendering is not only rasterization; it involves higher-level steps like CSS-driven layout, scene graph transformation, resource and state management, caching, etc. Compared to other GPU-accelerated platforms, JavaFX has the extra advantage of offloading this high-level rendering from the EDT, increasing multicore efficiency without any effort or risk. Not to mention “business” machines without appropriate support for full GPU acceleration; in this case JavaFX will do software rendering, and if the system has at least a dual-core CPU (or even a single-core but hyperthreaded clunker), the concurrent rendering will provide some advantage.
There are still APIs like Platform.runLater() and javafx.async; you don’t want to perform slow operations like I/O in the EDT to avoid unresponsiveness to user events. And you can also tap into the full power of JavaSE’s concurrency.
[/quote]
