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
<mailto: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
