Page History

...

On some machines VRAM is (or used to be) very fast special purpose memory. Currently on many systems, and on most embedded systems, VRAM is allocated (or reserved) from the main system memory. VRAM is consumed by the actual frame buffer (often with two copies allocated for quick swapping of the front and back buffer), and by GPU resources such as image/texture maps, as well as other system needs.

...

The JavaFX texture caching mechanism currently defaults to 256 512 MBytes.

For On desktop configurations, there VRAM configuration is not normally an issue, and many systems share system and vram. For some intensive applications, changing the JavaFX cache size may boost performance.

For embedded devices , the JavaFX default, which was chosen based on typical desktop configurations, may actually exceed the available memory. The  For example, the minimum recommended memory split for JFX on the Pi is 128 MBytes, with many applications requiring 256 MBytes.

This Since the JavaFX texture caching mechanism currently defaults to 256 512 MBytes - a value that will likely exceed what is available on the Pi. Given the limited amount of VRAM on the Pi, it is quite possible that an image intensive application might fail when the cache exceeds the available system limit.

...

To debug a JavaFX application failure to allocate VRAM, -Dprism.poolstats=true can be used to monitor the actual usage of the texture pool to better determine the upper limit.

In general, JavaFX will try to use no more than Another property setting -Dprism.targetvram=xx is used to limit the amount of VRAM that the texture cache will use at any given time, freeing textures that are no longer likely to be re-used when this value is exceeded. Least used textures will be discarded, and recreated on need. The . If too many recently used textures would be discarded for a given target, the target is raised, subject to the maximum limit controled by the maxram property.  The default for this setting is calculated as 75% 1/8th of the  maxvram setting, equal to 45M about 11M for the example of 90M. This fractional setting works well for desktop applications, but may be overly aggressive a bit restrictive during the startup phases for some embedded applications, and . The system will naturally raise the target appropriately, but some experimentation with a larger value and  -Dprism.poolstats=true may result in more performancebetter startup performance.  The property -Dprism.verbose=true can also be used to monitor when the target for the default texture pool is raised and a more appropriate initial target can be chosen for a given application.

Platform Specific Notes

...