Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8177635

Optimise CSS lookup resolution


    • Type: Enhancement
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: 8, 9, 10
    • Fix Version/s: tbd
    • Component/s: javafx
    • Labels:


      From my conversations with David Grieve, he noted that resolving lookups in CSS could be improved through design changes. Below is a his comments to me:

      Resolving lookups is expensive. This happens in CssStyleHelper#resolveLookups. The problem here is finding what style resolves the lookup. It is very recursive. You have to look at the styles of the current node, then of the parent node, and so on until you find the style or run out of parents. This happens for every lookup. In fact, there is a lot of this "going up the tree from child to parent" in the CSS code, and I think that is a performance bottleneck. So let me take a side track for a moment...

      In general, I wanted to change css processing so the information was passed down instead of looked up. CSS is applied top-down since child styles may depend on parent styles. So, at a minimum, if the parent passed down its pseudo-class state and font style, it would be a huge win. Each node would add its pseudo-class state to a Set<PseudoClassState>[] (or Stack<Set<PseudoClassState>> - the reason things are [] is because they are more efficient). If the node had a font from a style, it would overwrite the one passed in. Really, I think its just passing some kind of CssState object to Node#processCSS and then using it on the impl side. Not a trivial change, but one well worth looking into.

      Back to resolving lookups...

      We know from the parser what values need to be looked up. The parser keeps track of the properties as it goes and if it finds a value that is a property, well, that's a lookup (there is an issue there where it thinks some keywords are lookups, FYI). So now we should be able to have a map of 'properties that might need looked up'. If, as CSS is applied, that map was passed down and updated by each parent, the lookup would just be 'if I don't have the style, get the value from the map'. You'd want to pass a copy of the map to the child, of course, and that's where this gets a little sticky. If you have a really deep tree, you could end up with a lot of copies. So maybe a Map<String, Stack<ParsedValue>> would be better than passing a copy down. Or maybe Maybe a Map<String,Stack<Pair<Node,ParsedValue>>> so only the node that pushed onto the stack can pop and you only push if you have a matching style.


          Issue Links



              • Assignee:
                aghaisas Ajit Ghaisas
                jgiles Jonathan Giles
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: