EM Font Size Performance

[Dean Wookey]

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.grieve at 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.grieve at 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
>>>
>>
>>
>
>