OK, benchmark is kind of a bad name for it, although I am kind of using them in this way. Anyway, I added rt/apps/performance/GraphicsPerformance. This project contains a set of apps within it, such as nodecount.RectBench, nodecount.ImageBench, startup.StartupApp, preloader.SlowStartingApp, etc. which can be used for gathering performance data in a variety of scenarios.
The "startup" package contains tests for testing startup speeds. The initial app there "StartupApp" is probably poorly named and should be "SimplestAppEver". It has a Group for its root. This is the simplest app you can create and we want to use it to measure startup time. As specified in the class documentation: /** * A very basic application for testing startup. You must make sure to have: * -Dsun.perflog * -Dsun.perflog.fx.firstpaintflush * * both specified so that you get the startup metrics. You may also want: * -verbose:class * * to be able to see which classes are being loaded. */ This package needs to be fleshed out with other variants -- such as one that creates a bunch of invisible nodes, one that creates a Control, one that creates a WebView, etc. This will give us some idea of the startup times for typical use cases. The "preloader" package contains a sample PreloaderApp which is nothing but a ProgressBar, and a SlowStartingApp which sleeps in its init() method. The point of this one is to show that the preloader does work on iOS, and that the preloader can startup faster than waiting for the whole app, and that the preloader will continue to animate well even with all the background loading going on. I just recently added preloader support for desktop & iOS (haven't tried it on RoboVM yet but I would imagine it should work). The "nodecount" package contains tests which are designed so that they add nodes without adding pixels. The tests will lay out the nodes in a grid, and as you increase the number of nodes, I decrease the size of each node so that the number of pixels we fill remains constant (or near enough). I want the data from these tests to tell me what the incremental cost is of adding more nodes, not the cost of filling lots of overlapping nodes. The number of nodes being handled will be insignificant on desktop, however on embedded these numbers should be useful. Note that you ought to run with -Djavafx.animation.fullspeed=true in order to not have an artificial cutoff to your FPS numbers. Richard
