I agree. In fact, the Button cases which end up not being pixel snapped cause
huge performance loss (run ButtonBench on desktop). If you whip up a quick file
I'll add it in (I'm busy at the moment chasing down scrolling button
performance issues…).
The shadow issue I'm not sure about -- ideally we would do shadows directly in
the shader without having to render to a texture first (at least for leaf
nodes?) but I haven't thought about it enough to know if that is even feasible.
Richard
On Aug 26, 2013, at 5:17 PM, Scott Palmer swpal...@gmail.com wrote:
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
