This is almost a year old, but I think I've found a partial solution (David's suggestions on a top down approach still make sense, but that's a bigger issue). Caching an uncached call to lookupFont definitely improves performance.
https://github.com/DeanWookey/openjdk-jfx/commit/e12f00fb6c2fc690c0a7fb089f7b0c81d6930fa9 Using a stack of 50 stackpanes instead of 20, I now get the following: Before modification: With setting font size: 10675ms Without setting font size: 49243ms After modification: With setting font size: 10852ms Without setting font size: 20357ms Dean On Thu, Apr 19, 2018 at 9:51 PM David Grieve <david.gri...@oracle.com> wrote: > I was thinking about https://bugs.openjdk.java.net/browse/JDK-8177635 and > https://bugs.openjdk.java.net/browse/JDK-8090462 > > There is also https://bugs.openjdk.java.net/browse/JDK-8187955 > > On 4/19/18 3:02 PM, Nir Lisker wrote: > > I think this is the issue: > https://bugs.openjdk.java.net/browse/JDK-8088615. There's also > https://bugs.openjdk.java.net/browse/JDK-8193445. > > - Nir > > On Thu, Apr 19, 2018 at 1:42 PM, David Grieve <david.gri...@oracle.com> > wrote: > >> Resolving the relative size involves a lot of lookup. You have to go up >> the scene-graph from the child to find a font style. If you get to the root >> and haven't found a font style, then use the default font. Performance in >> this area could be vastly improved by passing the size from either a font >> style or the default font down the scene-graph as styles are evaluated. >> There are other style lookups that could benefit from this as well, >> resolving looked-up colors for example. I believe I created a bug for this >> a long time ago. >> >> >> >> On 4/19/18 5:57 AM, Dean Wookey wrote: >> >>> Hi All, >>> >>> In our application we add and remove a lot of nodes to the scene graph >>> regularly, and also make use of em font sizes to scale certain parts of >>> our >>> application. We've noticed performance issues when adding nodes to the >>> scene, and it seems to be related to em sizes in our css. >>> >>> As a test we added a chain of 20 stackpanes to a root stackpane. On the >>> root, we set a font size of 8pt via inline css. We then added and >>> removed a >>> new tableview from the deepest stackpane 500 times, waiting for the node >>> to >>> render after each add and remove. >>> >>> In each of the experiments, we compared adding tableviews without css and >>> adding tableviews with an inline css font size of 8pt. We then tried >>> setting different font sizes in the stackpane chain. >>> >>> I've attached sample code for these experiments. >>> >>> The results (on jdk 9.0.4 - jdk 10 was similar) are as follows: >>> >>> Setting a 1em font size on all stackpanes except the root. >>> With font on tableview: 14707ms >>> Without font on tableview: 27725ms >>> >>> Setting a 1em font size on the first child of the root only. >>> With font on tableview: 14221ms >>> Without font on tableview: 19187ms >>> >>> Using the original setup with no additional fonts. >>> With font on tableview: 13990ms >>> Without font on tableview: 13847ms >>> >>> It looks like using a relative font size has a large effect performance >>> wise on descendant nodes. I would expect some amount of font size caching >>> in the chain of stackpanes since I'm reusing the same chain and >>> adding/removing nodes from that chain repeatedly. >>> >>> I'm not sure how valid my test is, or how much of an issue this really is >>> in practice? >>> >>> Dean >>> >> >> > >
