This is very good. Looking forward to it growing. There's going to be a lot of work in building and maintaining that - would be great if it gets the love it needs.
I do wonder if there should be a separate guide for embedded and mobile as they really are a set of unique problems that you probably only care about if doing that sort of stuff. Might help keep the desktop one more digestible. A couple of questions to add (sure I will have more over time): 1) turning cache to true and cache hint to SPEED I haven't seen explained what the drawbacks are to doing this. I assume there is some trade-off for turning this on otherwise it would be on by default? 2) AnimationTimer - how is this related to transitions (like TransitionTimer). They seem to be two very different things - not just at the usage level but the actual underlying performance and implementation - but it's not clear to me exactly the difference. I wanted to work with both AnimationTimer stuff and Transitions in a consistent way (e.g. pause one thing to pause my whole app). When trying to use the API my instinct was that the transitions used an underlying AnimationTimer, so I was looking for a way to setAnimationTimer on the transitions, so they all shared the same instance. I'm obviously seeing it wrong, but it's not clear to me why these things are so different. 3) If I have an app with multiple views (say 20 or 30) and I want to animate between them (slide in, out, etc). Should I have all the views already added to the scene and then just move them off-center (and/or make them invisible), or should I add and remove them at the start and end of each animation. I'd assumed that adding and removing was the way to go for performance, is this correct? The question really is: If a node is in the scene graph but not visible does it add much overhead to rendering, picking, etc? Doing something like Mac's Mission Control would be much easier if I didn't have to add/remove and could just zoom, but is this a bad idea from performance perspective? 4) Is there much of a hit in building a view full of nodes and then throwing them away and rebuilding on each showing of that view? In my apps (browser style) I would build all the views on startup and then reuse these by loading different data into them (e.g. the same instance was used for showing Person1 details as Person2, just loading different values into it). I thought this would be the best from performance, but there was a comment from Richard a while back that suggested it was perfectly ok/performant to throw away and build the page again on each showing? This would be much easier from an animation point of view as animating the transition 'back' or 'forward' between two pages of the same view is problematic when you are reusing the same view for both! 5) Is there much overhead to a view that it is in memory but not actually added to the scene. i.e. if I do end up building a new instance of the view for every "page load" (as per question 4), then it would be extra handy to just keep those views in memory so when the back button is hit I don't have to rebuild them. I assume the memory would build up pretty quickly if there were large tables, images, videos, etc? How does a web browser manage to cache all these pages in history and would the same approach be performant for JFX? On Tue, Jun 4, 2013 at 7:11 AM, Richard Bair <[email protected]>wrote: > Hi, > > We had a brief meeting this afternoon and kicked off a performance tips n' > tricks wiki page, which is presently a dumping ground of ideas that will > get massaged into something useful. The content on this wiki will then be > used by the docs team to produce some official documentation that goes on > the oracle website. > > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks > > I pre-loaded it with a chunk of John Smith's email listing a bunch of > different performance related ideas, and also stuff we had on an internal > document we'd brainstormed up a while ago, plus some ideas we brainstormed > up a few minutes ago. Its rough, but if you are interested in taking a look > and giving more ideas that occur, I'd appreciate it. > > Thanks > Richard
