Page History

This page contains a series of ideas, each of which should be tied to a specific JIRA where the discussion / resolution will occur.

Graphics

Reducing State Switches

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.

Optimize String Measuring (Cache or Call less)

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.

Controls

Reducing Redundant Relayout

...

1. Verify that all of the Nodes (such as Controls) which can be content roots are properly identified as such. For example, the TableView, ListView, and TreeView should be content roots.
2. When running a layout pass, have the ability to determine whether a dirty layout node's pref / min / max size has changed. If not, then we have no need to run layout on this node, but can proceed to asking the dirty layout children to lay out themselves.
3. During a typical layout pass, the parent asks each child for its prefWidth, prefHeight, minWidth, minHeight, maxWidth, and maxHeight (or maybe 4 of those 6). It then proceeds to perform the layout algorithm 3 or more times. Suppose I have root R and layout container L with children C1-C3. When R attempts to lay itself out, it first asks L for its prefWidth (say). To figure out its pref width, L must get the pref width / height of C1 - C3 and perform the layout algorithm, so that it knows what its preferred width is. R then asks L for its minWidth (say), and L must then ask for the min width of C1 - C3 and run the layout algorithm to figure out what its min width is. And so forth. Multiple passes on complex layout algorithms is likely hurting us substantially. In retrospect I might have said that min/max was never computed only ever specified manually, which would have probably had a big positive impact in terms of performance. Nevertheless, the fact that we have to run this multiple times even when not strictly necessary is probably a cause of poor performance.

Preinitialize Controls to Well Know CSS Default Values

Rather than running CSS at start up, precompute the defaults and initialize FX to have these values.  This should improve start up time.

Other Ideas

Investigate Native GUI Timer, Pulses and Event Flow

...

There is some annicdotal evidence that suggests using the native GUI timer on OS X improves performance.

Preinitialize Controls to Well Know CSS Default Values

Rather than running CSS at start up, precompute the defaults and initialize FX to have these values.  This should improve start up time.

Support Instancing in JavaFX / Better Texture Caching

...

Instancing would allow the application programer to declare that identical nodes are shared in the render tree.  This would allow the system to cache and optimize drawing.

Optimize String Measuring (Cache or Call less)

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.