HTMLEditor font selector slowness

[Jonathan Giles]

I was going to reply with the default statement that ComboBox, basically
being a button that shows a ListView, was already relatively well
optimised and that it would only be creating cells (containing the Font
objects) in the visible area, but interestingly this doesn't seem to be
the case. I can see that if I click on the font family ComboBox that it
is calling updateItem for all fonts on my system. Also interesting is
that it does this every time the popup is shown. I'm not sure why that
is right now.

This is most probably the reason for the slowdown, but it is hard to be
entirely certain until I squash this bug. The other side of the coin is
that the graphics engine may be having to expend more effort the first
time it encounters each font, so there may be a greater cost on that
side too. Nonetheless, I'll look into my side first...

I've filed https://javafx-jira.kenai.com/browse/RT-32906 to track this.

-- Jonathan

On 12/09/2013 7:22 p.m., John C. Turnbull wrote:
> Just a quick note about HTMLEditor. I find that the font selector takes a
> very long time to load the list of fonts the first time it is clicked on and
> while it is loading the entire app locks-up.
>
>  
>
> I realise that it needs to render each font name using the actual font
> itself (so it probably has to instantiate each Font object) but similar
> drop-downs in Word for example do exactly the same thing and load almost
> instantaneously.
>
>  
>
> Is there some reason why opening the drop-down font list take so long the
> first time it is clicked?  Could this be optimised some way by just loading
> enough fonts to fill about 2 "pages" of fonts and then loading the rest in a
> lazy manner?
>
>  
>
> I am working with JDK8 b106 but the same thing happens with JDK7 as well.
>
>  
>
> -jct
>