The root element font metrics were getting queried again and again
during style computation. Before this change we would do some work to
recalculate them each time.
This patch simply caches them in a StyleComputer member. Since style
updates always start with the root element, we know that it'll be
up-to-date by the time we look at any other element.
Before this change, we were spending ~5% of CPU time on Google Groups
in root_element_font_metrics().
Old pattern:
foo.resolved(node, reference_value).to_px(node)
New pattern:
foo.to_px(node, reference_value)
Also, the reference value for to_px() is a CSSPixels, which means we
don't have to synthesize a CSS::Length just for this call.
This necessitated returning `nullptr` instead of just `{}` in a lot of
places. Also, some temporary hackiness in `parse_css_value()`: That
returns a special `ParseError` type already, so we now have a
`FIXME_TRY()` macro which logs the error and then returns a generic
`ParseError::InternalError` value. Eventually this macro will go away,
once I figure out how to deal with this more nicely.
In particular, we now blockify layout internal boxes (e.g table parts)
by turning them into `block flow`. This fixes a crash when viewing
our GitHub repo :^)
The Display class already supported all specific values, and now they
will be parsed too. The display property now has a special type
DisplayStyleValue.
Length units are either relative to the font, or to the viewport, but
never both. So we can save some work by not gathering font metrics for
a viewport unit, and not retrieving the viewport for a font unit.
Currently this is only helpful when the `to_px(Layout::Node)` method is
called, but since that is 208 places according to CLion, (plus 33
indirect uses via `Length::resolved()`) it still seems worthwhile. :^)
`*vi` and `*vb` vary on which direction they check depending on whether
the writing mode is horizontal or vertical, so they will need some
modification once we support that.
Using the rough heuristic instead of the actual spec measurement. It's
allowed by the spec, but not ideal:
> In the cases where it is impossible or impractical to determine the
ideographic advance measure, it must be assumed to be 1em.
As noted, the ascent of the font is not the best heuristic for this, but
it is one that's listed as OK to use by the spec:
> In the cases where it is impossible or impractical to determine the
cap-height, the font’s ascent must be used.
Rather than passing an increasingly-unwieldy number of font parameters
individually to every function that resolves lengths, let's wrap them
up.
This is frustratingly close to being `Gfx::FontPixelMetrics`, but bitmap
fonts cause issues: We choose the closest font to what the CSS
requests, but that might have a wildly different size than what the
page expects, so we have to fudge the numbers.
No behaviour changes.
They previously weren't sorted at all. Alphabetical would be nice, but
then things like `em` and `rem` would be separated. So, let's copy the
spec's order. That way it's easier to keep track of which units we have
or haven't implemented. (Since there are so many...)
This bit is mostly ad-hoc for now. This simply turns fill: url(#grad1)
into document().get_element_by_id('grad1') then resolves the gradient.
This seems to do the trick for most use cases, but this is not
attempting to follow the spec yet to keep things simple.
This will be needed to access the color of a stop from a SVG gradient
<stop> element (which does not participate in layout, so does not have
a layout node).
When deciding on a box type transformation (blockify/inlinify) for a
pseudo element, we have to use the originating element as a reference
rather than the parent.
(The originating element *is* the parent for its pseudo elements.)
This appears to be consistent with other engines, and fixes many pages
where we were misinterpreting super large z-index values as something
else entirely.
Now that LengthStyleValue never contains `auto`, IdentifierStyleValue is
the only type that can hold an identifier. This lets us remove a couple
of virtual methods from StyleValue.
I've kept `has_auto()` and `to_identifier()` for convenience, but they
are now simple non-virtual methods.
Previously, whether trying to parse a `<length>` or `<dimension>`, we
would accept `auto` and produce a `LengthStyleValue` from it. This
would fool the `property_accepts_value()` into allowing `auto` where it
does not belong, if the property did accept lengths.
Of the few places in the parser that called `parse_dimension_value()` or
`parse_length()`, none of them were expecting it to accept `auto`, so
this fixes those too. :^)
Currently, `property_accepts_value()` always returns `true` if the
property is a shorthand. (This is a bug, and should actually be fixed
properly at some point...) This means that all identifiers are caught
here, including `auto`, which should be handled by the `flex-basis`
branch instead.
This works currently because `auto` is a LengthStyleValue, but that's
about to change!
