An investigation of the com.sun.scenario.Settings class is in order:

* We should asses the overall classloading cost of current Settings implementation

* The initial motivation for Settings was to provide easy access from Applets, which don't typically have permissions to set System Properties. There may now be ways to provide similar/acceptable functionality from JavaFX Applets.

* Possibly investigate how widespread the usage of Settings is. It has been a "semi-internal" interface, useful for debugging, yet with access to some features (such as fullspeed) likely to be of interest to some app developers

* Responding to Settings changes after initial values are set (currently via PropertyChanges) (as opposed to only setting values when certain classes are initialized, via static{}) makes Settings work reliably in the face of sometimes-brittle class initialization order. Perhaps it's worth writing a more minimal notification system, at least for use under Prism.

In short, we should evaluate the current use and implementation of Settings, with an eye towards minimizing unnecessary classloads under Prism while maintaining sufficient functionality compatibility.