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
