Performance Tips n' Tricks wiki page

[Daniel Zwolenski]

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 <richard.bair at oracle.com>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