This page contains a series of ideas, each of which should be tied to a specific JIRA where the discussion / resolution will occur.
Graphics
Command Buffer
Right now, JFX has two threads: The UI thread and the Render thread. The render thread currently works in direct mode. It traverses the render graph hierarchy and issues graphics commands to the card. This incurs latency on some calls when the render thread needs to wait for the graphics card to execute the current operation. When a node is rendered, the output is normally a request to run a certain shader and a set of vertices for the shader. Rather than talking directly to the card, the command buffer saves a list of commands and their arguments and then puts the final result together to give to the graphics card.
How does this improve performance? Since graphics commands are saved, the Java code that computes vertices does not need to run. More importantly, threads can compute command buffers concurrently and not incur latency from the graphics card.
https://javafx-jira.kenai.com/browse/RT-23462
Multi-Threading
Modern CPU's have many more cores that could be taken advantage of so multi-threaded rendering is a necessity. Using a command buffer, multiple threads can process branches of the render graph hierarchy. A single render thread is responsible for executing the command buffers. While command buffer threads are executing, they can request resources from the render thread so that when it comes time to execute the buffer, textures and other resources have been created.
Reducing State Switches ("super shader")
This idea is based on the fact that with Region caching enabled, almost everything we do is rendering images and text. Right now, the first time a checkbox is rendered (for example), we first render it to an image, store the image in a cache, and thereafter whenever we have to render the checkbox we do so by rendering the cached image (simplified, but you get the point). When we render text, we are also rendering images, but with a different shader. At the moment that means that to render a checkbox, we first setup the shader for rendering from an image, render, and then switch to the text shader and render text. If you have a page with 20 check boxes, we end up doing 40 state switches.
...
Preliminary testing with CheckBox seems to indicate a potential 6x improvement in performance for this case (where you have a hundred or so check boxes on the scene). The numbers for TableView were only marginally better – perhaps due to the overhead in CSS / Layout related to the table, although this analysis is speculative.
https://javafx-jira.kenai.com/browse/RT-30741
https://javafx-jira.kenai.com/browse/RT-30922
...
Preserve the Back Buffer
If we are not updating the whole screen on each pulse then we could benefit from preserving the framebuffer. We would need to explicitly clear dirty regions before rendering to them.
Optimize String Measuring
It is no secret that the cost of string measuring can have a huge effect on performance. String measuring operations are called often in FX to determine the preferred size of controls and layout happens often in FX as application code changes the contents of controls.
It's easy to see the same strings being measured over and over again. We could fix the callers to cache/call less or cache way down deep inside of Prism.
https://javafx-jira.kenai.com/browse/RT-30158
Implement Hardware Layers
We could be taking advantage of hardware layers to speed up composition.
https://javafx-jira.kenai.com/browse/RT-30719
Smooth Animation
This is not a performance optimization silky smooth animation makes a program seem faster and look more polished.
Controls
Reducing Redundant Relayout
...
Overview
Content Tools
ThemeBuilder