[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: EM Font Size Performance
From:       Dean Wookey <wookey.dean () gmail ! com>
Date:       2019-01-18 8:28:59
Message-ID: CAKZ_BFgoPbhXv-TFHJeMQD1B2Yyh0c8ATOKFL8DJpeK-UGkGzQ () mail ! gmail ! com
[Download RAW message or body]

I've only tested with our application that includes all those things. We
set a font size on the root node and everything is done in em. The user can
change the font size of the root node, which filters down to things like
tooltips, context menus, tables etc.

Do you know if there are tests specifically for these things?

Otherwise, I'm not 100% happy with this fix because I feel it makes things
more confusing. In my opinion the lookupFont should cache itself, or there
should be a cachedLookupFont which does this. I don't really understand the
special cases of SKIP and null however, so I replicated the steps used to
cache the result elsewhere. I think it would be better if someone else made
a more comprehensive fix which made things a little clearer.

Dean

On Thu, Jan 17, 2019 at 6:41 PM David Grieve <david.grieve@oracle.com>
wrote:

> I think the change looks reasonable. Has it been tested against things
> like changing -fx-font in some parent, or setting the font property in some
> parent? What about popups? If I have a tooltip on a Label, for example,
> does the tooltip properly pick up font from the Label's style or font
> property?
> On 1/17/19 11:10 AM, Dean Wookey wrote:
> 
> 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
>  <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DeanWookey_openjdk \
> -2Djfx_commit_e12f00fb6c2fc690c0a7fb089f7b0c81d6930fa9&d=DwMFaQ&c=RoP1YumCXCgaWHvlZY \
> R8PZh8Bv7qIrMUB65eapI_JnE&r=H6jKHjHoLf6vCNF0PYEnJ6cS6kScbGLraJqgoRs9znU&m=xH8dfYiQe6 \
> JO5VXucoVgtnsubTZNAhr0XVK5OaSDDbs&s=YvsZxESGrm40L34aR16E2fQCKjh8tCQ311R3h63hu0c&e=> \
>  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@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@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
> > > > 
> > > 
> > > 
> > 
> > 


[prev in list] [next in list] [prev in thread] [next in thread]