Might I suggest "nodecount.PathBench" I bring it up because Path performance is costly for my app, when it represents a fraction of the number of pixels rendered. I.e. it could use some attention and with a test app like these at least you will know when things are going in the right direction performance-wise.
I also use effects on the paths to highlight them on mouse over so users can easily see which path they will select.. That has the unfortunate side-effect of converting the path to a raster which could be very large. I'm actually hitting resource problems just because I add a shadow to a path for UI feedback Scott On 2013-08-26, at 7:34 PM, Richard Bair <richard.b...@oracle.com> wrote: > 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
