Performance "benchmarks"

Scott Palmer swpalmer at
Mon Aug 26 17:17:16 PDT 2013

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


On 2013-08-26, at 7:34 PM, Richard Bair <richard.bair at> 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

More information about the openjfx-dev mailing list