2020-01-18 09:38:21 +01:00
|
|
|
/*
|
2024-10-04 13:19:50 +02:00
|
|
|
* Copyright (c) 2018-2024, Andreas Kling <andreas@ladybird.org>
|
2024-08-23 11:03:05 +01:00
|
|
|
* Copyright (c) 2021-2024, Sam Atkins <sam@ladybird.org>
|
2020-01-18 09:38:21 +01:00
|
|
|
*
|
2021-04-22 01:24:48 -07:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-01-18 09:38:21 +01:00
|
|
|
*/
|
|
|
|
|
2019-06-27 17:47:59 +02:00
|
|
|
#pragma once
|
|
|
|
|
2021-12-03 20:00:31 +00:00
|
|
|
#include <AK/HashMap.h>
|
2022-02-24 15:54:12 +00:00
|
|
|
#include <AK/Optional.h>
|
2019-09-21 15:32:17 +03:00
|
|
|
#include <AK/OwnPtr.h>
|
2024-06-28 20:27:00 +02:00
|
|
|
#include <LibGfx/Font/Typeface.h>
|
2024-02-22 13:56:15 +00:00
|
|
|
#include <LibWeb/Animations/KeyframeEffect.h>
|
2022-03-29 02:14:20 +02:00
|
|
|
#include <LibWeb/CSS/CSSFontFaceRule.h>
|
2023-05-26 23:30:54 +03:30
|
|
|
#include <LibWeb/CSS/CSSKeyframesRule.h>
|
2021-05-24 23:02:58 +02:00
|
|
|
#include <LibWeb/CSS/CSSStyleDeclaration.h>
|
LibWeb: Split StyleComputer work into two phases with separate outputs
Before this change, StyleComputer would essentially take a DOM element,
find all the CSS rules that apply to it, and resolve the computed value
for each CSS property for that element.
This worked great, but it meant we had to do all the work of selector
matching and cascading every time.
To enable new optimizations, this change introduces a break in the
middle of this process where we've produced a "CascadedProperties".
This object contains the result of the cascade, before we've begun
turning cascaded values into computed values.
The cascaded properties are now stored with each element, which will
later allow us to do partial updates without re-running the full
StyleComputer machine. This will be particularly valuable for
re-implementing CSS inheritance, which is extremely heavy today.
Note that CSS animations and CSS transitions operate entirely on the
computed values, even though the cascade order would have you believe
they happen earlier. I'm not confident we have the right architecture
for this, but that's a separate issue.
2024-12-12 10:06:29 +01:00
|
|
|
#include <LibWeb/CSS/CascadeOrigin.h>
|
|
|
|
#include <LibWeb/CSS/CascadedProperties.h>
|
2024-12-20 11:32:17 +01:00
|
|
|
#include <LibWeb/CSS/ComputedProperties.h>
|
2022-02-24 15:54:12 +00:00
|
|
|
#include <LibWeb/CSS/Selector.h>
|
2025-01-12 18:38:05 +03:00
|
|
|
#include <LibWeb/CSS/StyleInvalidationData.h>
|
2020-07-26 19:37:56 +02:00
|
|
|
#include <LibWeb/Forward.h>
|
2024-05-15 14:58:24 -06:00
|
|
|
#include <LibWeb/Loader/ResourceLoader.h>
|
2019-06-27 17:47:59 +02:00
|
|
|
|
2020-07-26 20:01:35 +02:00
|
|
|
namespace Web::CSS {
|
2020-03-07 10:27:02 +01:00
|
|
|
|
LibWeb: Use an ancestor filter to quickly reject many CSS selectors
Given a selector like `.foo .bar #baz`, we know that elements with
the class names `foo` and `bar` must be present in the ancestor chain of
the candidate element, or the selector cannot match.
By keeping track of the current ancestor chain during style computation,
and which strings are used in tag names and attribute names, we can do
a quick check before evaluating the selector itself, to see if all the
required ancestors are present.
The way this works:
1. CSS::Selector now has a cache of up to 8 strings that must be present
in the ancestor chain of a matching element. Note that we actually
store string *hashes*, not the strings themselves.
2. When Document performs a recursive style update, we now push and pop
elements to the ancestor chain stack as they are entered and exited.
3. When entering/exiting an ancestor, StyleComputer collects all the
relevant string hashes from that ancestor element and updates a
counting bloom filter.
4. Before evaluating a selector, we first check if any of the hashes
required by the selector are definitely missing from the ancestor
filter. If so, it cannot be a match, and we reject it immediately.
5. Otherwise, we carry on and evaluate the selector as usual.
I originally tried doing this with a HashMap, but we ended up losing
a huge chunk of the time saved to HashMap instead. As it turns out,
a simple counting bloom filter is way better at handling this.
The cost is a flat 8KB per StyleComputer, and since it's a bloom filter,
false positives are a thing.
This is extremely efficient, and allows us to quickly reject the
majority of selectors on many huge websites.
Some example rejection rates:
- https://amazon.com: 77%
- https://github.com/SerenityOS/serenity: 61%
- https://nytimes.com: 57%
- https://store.steampowered.com: 55%
- https://en.wikipedia.org: 45%
- https://youtube.com: 32%
- https://shopify.com: 25%
This also yields a chunky 37% speedup on StyleBench. :^)
2024-03-22 13:50:33 +01:00
|
|
|
// A counting bloom filter with 2 hash functions.
|
|
|
|
// NOTE: If a counter overflows, it's kept maxed-out until the whole filter is cleared.
|
|
|
|
template<typename CounterType, size_t key_bits>
|
|
|
|
class CountingBloomFilter {
|
|
|
|
public:
|
|
|
|
CountingBloomFilter() { }
|
|
|
|
|
|
|
|
void clear() { __builtin_memset(m_buckets, 0, sizeof(m_buckets)); }
|
|
|
|
|
|
|
|
void increment(u32 key)
|
|
|
|
{
|
|
|
|
auto& first = bucket1(key);
|
|
|
|
if (first < NumericLimits<CounterType>::max())
|
|
|
|
++first;
|
|
|
|
auto& second = bucket2(key);
|
|
|
|
if (second < NumericLimits<CounterType>::max())
|
|
|
|
++second;
|
|
|
|
}
|
|
|
|
|
|
|
|
void decrement(u32 key)
|
|
|
|
{
|
|
|
|
auto& first = bucket1(key);
|
|
|
|
if (first < NumericLimits<CounterType>::max())
|
|
|
|
--first;
|
|
|
|
auto& second = bucket2(key);
|
|
|
|
if (second < NumericLimits<CounterType>::max())
|
|
|
|
--second;
|
|
|
|
}
|
|
|
|
|
|
|
|
[[nodiscard]] bool may_contain(u32 hash) const
|
|
|
|
{
|
|
|
|
return bucket1(hash) && bucket2(hash);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
static constexpr u32 bucket_count = 1 << key_bits;
|
|
|
|
static constexpr u32 key_mask = bucket_count - 1;
|
|
|
|
|
|
|
|
[[nodiscard]] u32 hash1(u32 key) const { return key & key_mask; }
|
|
|
|
[[nodiscard]] u32 hash2(u32 key) const { return (key >> 16) & key_mask; }
|
|
|
|
|
|
|
|
[[nodiscard]] CounterType& bucket1(u32 key) { return m_buckets[hash1(key)]; }
|
|
|
|
[[nodiscard]] CounterType& bucket2(u32 key) { return m_buckets[hash2(key)]; }
|
|
|
|
[[nodiscard]] CounterType bucket1(u32 key) const { return m_buckets[hash1(key)]; }
|
|
|
|
[[nodiscard]] CounterType bucket2(u32 key) const { return m_buckets[hash2(key)]; }
|
|
|
|
|
|
|
|
CounterType m_buckets[bucket_count];
|
|
|
|
};
|
|
|
|
|
2020-06-13 00:44:26 +02:00
|
|
|
struct MatchingRule {
|
2024-11-15 04:01:23 +13:00
|
|
|
GC::Ptr<DOM::ShadowRoot const> shadow_root;
|
|
|
|
GC::Ptr<CSSRule const> rule; // Either CSSStyleRule or CSSNestedDeclarations
|
|
|
|
GC::Ptr<CSSStyleSheet const> sheet;
|
2025-01-26 13:58:28 +01:00
|
|
|
Optional<FlyString> default_namespace;
|
2025-01-25 19:57:11 +01:00
|
|
|
Selector const& selector;
|
2020-06-13 00:44:26 +02:00
|
|
|
size_t style_sheet_index { 0 };
|
|
|
|
size_t rule_index { 0 };
|
2024-03-13 11:47:25 +01:00
|
|
|
|
2021-05-24 23:01:24 +02:00
|
|
|
u32 specificity { 0 };
|
2024-03-18 16:01:47 +01:00
|
|
|
CascadeOrigin cascade_origin;
|
2023-03-09 19:27:23 +01:00
|
|
|
bool contains_pseudo_element { false };
|
2024-09-09 15:37:17 +02:00
|
|
|
bool must_be_hovered { false };
|
2024-10-17 13:48:00 +01:00
|
|
|
|
|
|
|
// Helpers to deal with the fact that `rule` might be a CSSStyleRule or a CSSNestedDeclarations
|
|
|
|
PropertyOwningCSSStyleDeclaration const& declaration() const;
|
|
|
|
SelectorList const& absolutized_selectors() const;
|
|
|
|
FlyString const& qualified_layer_name() const;
|
2020-06-13 00:44:26 +02:00
|
|
|
};
|
|
|
|
|
2024-10-26 23:35:58 +02:00
|
|
|
struct FontFaceKey;
|
|
|
|
|
|
|
|
struct OwnFontFaceKey {
|
|
|
|
explicit OwnFontFaceKey(FontFaceKey const& other);
|
|
|
|
|
|
|
|
operator FontFaceKey() const;
|
|
|
|
|
|
|
|
[[nodiscard]] u32 hash() const { return pair_int_hash(family_name.hash(), pair_int_hash(weight, slope)); }
|
|
|
|
[[nodiscard]] bool operator==(OwnFontFaceKey const& other) const = default;
|
|
|
|
[[nodiscard]] bool operator==(FontFaceKey const& other) const;
|
|
|
|
|
2023-05-24 15:35:30 +02:00
|
|
|
FlyString family_name;
|
|
|
|
int weight { 0 };
|
|
|
|
int slope { 0 };
|
|
|
|
};
|
|
|
|
|
2024-05-15 14:58:24 -06:00
|
|
|
class FontLoader;
|
|
|
|
|
2021-09-24 13:49:57 +02:00
|
|
|
class StyleComputer {
|
2019-06-27 17:47:59 +02:00
|
|
|
public:
|
2024-03-17 17:29:31 -07:00
|
|
|
enum class AllowUnresolved {
|
|
|
|
Yes,
|
|
|
|
No,
|
|
|
|
};
|
2024-08-14 11:10:54 +01:00
|
|
|
static void for_each_property_expanding_shorthands(PropertyID, CSSStyleValue const&, AllowUnresolved, Function<void(PropertyID, CSSStyleValue const&)> const& set_longhand_property);
|
LibWeb: Split StyleComputer work into two phases with separate outputs
Before this change, StyleComputer would essentially take a DOM element,
find all the CSS rules that apply to it, and resolve the computed value
for each CSS property for that element.
This worked great, but it meant we had to do all the work of selector
matching and cascading every time.
To enable new optimizations, this change introduces a break in the
middle of this process where we've produced a "CascadedProperties".
This object contains the result of the cascade, before we've begun
turning cascaded values into computed values.
The cascaded properties are now stored with each element, which will
later allow us to do partial updates without re-running the full
StyleComputer machine. This will be particularly valuable for
re-implementing CSS inheritance, which is extremely heavy today.
Note that CSS animations and CSS transitions operate entirely on the
computed values, even though the cascade order would have you believe
they happen earlier. I'm not confident we have the right architecture
for this, but that's a separate issue.
2024-12-12 10:06:29 +01:00
|
|
|
static void set_property_expanding_shorthands(
|
|
|
|
CascadedProperties&,
|
|
|
|
PropertyID,
|
|
|
|
CSSStyleValue const&,
|
|
|
|
GC::Ptr<CSSStyleDeclaration const>,
|
|
|
|
CascadeOrigin,
|
|
|
|
Important,
|
|
|
|
Optional<FlyString> layer_name);
|
2024-12-05 11:08:58 +00:00
|
|
|
static NonnullRefPtr<CSSStyleValue const> get_inherit_value(CSS::PropertyID, DOM::Element const*, Optional<CSS::Selector::PseudoElement::Type> = {});
|
2024-02-24 08:36:24 -07:00
|
|
|
|
2024-08-23 11:03:05 +01:00
|
|
|
static Optional<String> user_agent_style_sheet_source(StringView name);
|
|
|
|
|
2021-09-24 13:49:57 +02:00
|
|
|
explicit StyleComputer(DOM::Document&);
|
2022-03-29 02:14:20 +02:00
|
|
|
~StyleComputer();
|
2019-06-27 17:47:59 +02:00
|
|
|
|
2020-07-26 19:37:56 +02:00
|
|
|
DOM::Document& document() { return m_document; }
|
2021-07-14 16:56:11 +01:00
|
|
|
DOM::Document const& document() const { return m_document; }
|
2019-06-27 17:47:59 +02:00
|
|
|
|
LibWeb: Use an ancestor filter to quickly reject many CSS selectors
Given a selector like `.foo .bar #baz`, we know that elements with
the class names `foo` and `bar` must be present in the ancestor chain of
the candidate element, or the selector cannot match.
By keeping track of the current ancestor chain during style computation,
and which strings are used in tag names and attribute names, we can do
a quick check before evaluating the selector itself, to see if all the
required ancestors are present.
The way this works:
1. CSS::Selector now has a cache of up to 8 strings that must be present
in the ancestor chain of a matching element. Note that we actually
store string *hashes*, not the strings themselves.
2. When Document performs a recursive style update, we now push and pop
elements to the ancestor chain stack as they are entered and exited.
3. When entering/exiting an ancestor, StyleComputer collects all the
relevant string hashes from that ancestor element and updates a
counting bloom filter.
4. Before evaluating a selector, we first check if any of the hashes
required by the selector are definitely missing from the ancestor
filter. If so, it cannot be a match, and we reject it immediately.
5. Otherwise, we carry on and evaluate the selector as usual.
I originally tried doing this with a HashMap, but we ended up losing
a huge chunk of the time saved to HashMap instead. As it turns out,
a simple counting bloom filter is way better at handling this.
The cost is a flat 8KB per StyleComputer, and since it's a bloom filter,
false positives are a thing.
This is extremely efficient, and allows us to quickly reject the
majority of selectors on many huge websites.
Some example rejection rates:
- https://amazon.com: 77%
- https://github.com/SerenityOS/serenity: 61%
- https://nytimes.com: 57%
- https://store.steampowered.com: 55%
- https://en.wikipedia.org: 45%
- https://youtube.com: 32%
- https://shopify.com: 25%
This also yields a chunky 37% speedup on StyleBench. :^)
2024-03-22 13:50:33 +01:00
|
|
|
void reset_ancestor_filter();
|
|
|
|
void push_ancestor(DOM::Element const&);
|
|
|
|
void pop_ancestor(DOM::Element const&);
|
|
|
|
|
2024-12-20 16:35:12 +01:00
|
|
|
[[nodiscard]] GC::Ref<ComputedProperties> create_document_style() const;
|
2023-03-14 16:36:20 +01:00
|
|
|
|
2024-12-20 16:35:12 +01:00
|
|
|
[[nodiscard]] GC::Ref<ComputedProperties> compute_style(DOM::Element&, Optional<CSS::Selector::PseudoElement::Type> = {}) const;
|
|
|
|
[[nodiscard]] GC::Ptr<ComputedProperties> compute_pseudo_element_style_if_needed(DOM::Element&, Optional<CSS::Selector::PseudoElement::Type>) const;
|
2019-06-27 17:47:59 +02:00
|
|
|
|
2025-01-04 18:09:21 +03:00
|
|
|
Vector<MatchingRule> const& get_hover_rules() const;
|
2025-01-24 15:47:42 +01:00
|
|
|
[[nodiscard]] Vector<MatchingRule const*> collect_matching_rules(DOM::Element const&, CascadeOrigin, Optional<CSS::Selector::PseudoElement::Type>, bool& did_match_any_hover_rules, FlyString const& qualified_layer_name = {}) const;
|
2019-06-27 20:40:21 +02:00
|
|
|
|
2025-01-12 18:38:05 +03:00
|
|
|
InvalidationSet invalidation_set_for_properties(Vector<InvalidationSet::Property> const&) const;
|
|
|
|
bool invalidation_property_used_in_has_selector(InvalidationSet::Property const&) const;
|
|
|
|
|
2025-01-24 10:29:51 +01:00
|
|
|
[[nodiscard]] bool has_valid_rule_cache() const { return m_author_rule_cache; }
|
2022-02-10 17:49:50 +01:00
|
|
|
void invalidate_rule_cache();
|
|
|
|
|
2022-03-11 12:53:32 +00:00
|
|
|
Gfx::Font const& initial_font() const;
|
|
|
|
|
2023-02-17 14:06:55 +00:00
|
|
|
void did_load_font(FlyString const& family_name);
|
2022-03-29 02:14:20 +02:00
|
|
|
|
2024-05-17 17:14:06 -07:00
|
|
|
Optional<FontLoader&> load_font_face(ParsedFontFace const&, ESCAPING Function<void(FontLoader const&)> on_load = {}, ESCAPING Function<void()> on_fail = {});
|
2024-05-15 14:58:24 -06:00
|
|
|
|
2024-09-22 18:10:46 +02:00
|
|
|
void load_fonts_from_sheet(CSSStyleSheet&);
|
|
|
|
void unload_fonts_from_sheet(CSSStyleSheet&);
|
2022-04-08 21:27:35 +02:00
|
|
|
|
2024-12-22 21:34:50 +01:00
|
|
|
static CSSPixels default_user_font_size();
|
|
|
|
static CSSPixelFraction absolute_size_mapping(Keyword);
|
2024-08-14 11:10:54 +01:00
|
|
|
RefPtr<Gfx::FontCascadeList const> compute_font_for_style_values(DOM::Element const* element, Optional<CSS::Selector::PseudoElement::Type> pseudo_element, CSSStyleValue const& font_family, CSSStyleValue const& font_size, CSSStyleValue const& font_style, CSSStyleValue const& font_weight, CSSStyleValue const& font_stretch, int math_depth = 0) const;
|
2023-08-07 21:48:18 +02:00
|
|
|
|
2024-01-11 14:04:18 +01:00
|
|
|
void set_viewport_rect(Badge<DOM::Document>, CSSPixelRect const& viewport_rect) { m_viewport_rect = viewport_rect; }
|
|
|
|
|
2024-03-16 07:44:48 +01:00
|
|
|
enum class AnimationRefresh {
|
|
|
|
No,
|
|
|
|
Yes,
|
|
|
|
};
|
2024-12-20 11:32:17 +01:00
|
|
|
void collect_animation_into(DOM::Element&, Optional<CSS::Selector::PseudoElement::Type>, GC::Ref<Animations::KeyframeEffect> animation, ComputedProperties&, AnimationRefresh = AnimationRefresh::No) const;
|
2024-03-16 07:44:48 +01:00
|
|
|
|
2025-01-24 10:29:51 +01:00
|
|
|
[[nodiscard]] bool may_have_has_selectors() const;
|
2024-09-19 13:27:37 +02:00
|
|
|
|
2024-09-29 23:38:49 +02:00
|
|
|
size_t number_of_css_font_faces_with_loading_in_progress() const;
|
|
|
|
|
2024-12-20 16:35:12 +01:00
|
|
|
[[nodiscard]] GC::Ref<ComputedProperties> compute_properties(DOM::Element&, Optional<Selector::PseudoElement::Type>, CascadedProperties&) const;
|
LibWeb: Split StyleComputer work into two phases with separate outputs
Before this change, StyleComputer would essentially take a DOM element,
find all the CSS rules that apply to it, and resolve the computed value
for each CSS property for that element.
This worked great, but it meant we had to do all the work of selector
matching and cascading every time.
To enable new optimizations, this change introduces a break in the
middle of this process where we've produced a "CascadedProperties".
This object contains the result of the cascade, before we've begun
turning cascaded values into computed values.
The cascaded properties are now stored with each element, which will
later allow us to do partial updates without re-running the full
StyleComputer machine. This will be particularly valuable for
re-implementing CSS inheritance, which is extremely heavy today.
Note that CSS animations and CSS transitions operate entirely on the
computed values, even though the cascade order would have you believe
they happen earlier. I'm not confident we have the right architecture
for this, but that's a separate issue.
2024-12-12 10:06:29 +01:00
|
|
|
|
2024-12-22 11:59:58 +01:00
|
|
|
void absolutize_values(ComputedProperties&) const;
|
2024-12-23 17:51:10 +01:00
|
|
|
void compute_font(ComputedProperties&, DOM::Element const*, Optional<CSS::Selector::PseudoElement::Type>) const;
|
2024-12-22 11:59:58 +01:00
|
|
|
|
2025-01-28 03:04:04 +01:00
|
|
|
[[nodiscard]] bool should_reject_with_ancestor_filter(Selector const&) const;
|
|
|
|
|
2019-06-27 17:47:59 +02:00
|
|
|
private:
|
2023-03-14 16:36:20 +01:00
|
|
|
enum class ComputeStyleMode {
|
|
|
|
Normal,
|
|
|
|
CreatePseudoElementStyleIfNeeded,
|
|
|
|
};
|
|
|
|
|
2023-08-17 18:45:06 +02:00
|
|
|
struct MatchingFontCandidate;
|
2023-05-29 02:16:16 +00:00
|
|
|
|
2024-12-20 16:35:12 +01:00
|
|
|
[[nodiscard]] GC::Ptr<ComputedProperties> compute_style_impl(DOM::Element&, Optional<CSS::Selector::PseudoElement::Type>, ComputeStyleMode) const;
|
2025-01-03 20:39:25 +03:00
|
|
|
[[nodiscard]] GC::Ref<CascadedProperties> compute_cascaded_values(DOM::Element&, Optional<CSS::Selector::PseudoElement::Type>, bool& did_match_any_pseudo_element_rules, bool& did_match_any_hover_rules, ComputeStyleMode) const;
|
2023-12-09 23:42:02 +01:00
|
|
|
static RefPtr<Gfx::FontCascadeList const> find_matching_font_weight_ascending(Vector<MatchingFontCandidate> const& candidates, int target_weight, float font_size_in_pt, bool inclusive);
|
|
|
|
static RefPtr<Gfx::FontCascadeList const> find_matching_font_weight_descending(Vector<MatchingFontCandidate> const& candidates, int target_weight, float font_size_in_pt, bool inclusive);
|
2024-10-26 23:35:58 +02:00
|
|
|
RefPtr<Gfx::FontCascadeList const> font_matching_algorithm(FlyString const& family_name, int weight, int slope, float font_size_in_pt) const;
|
2024-12-20 11:32:17 +01:00
|
|
|
void compute_math_depth(ComputedProperties&, DOM::Element const*, Optional<CSS::Selector::PseudoElement::Type>) const;
|
|
|
|
void compute_defaulted_values(ComputedProperties&, DOM::Element const*, Optional<CSS::Selector::PseudoElement::Type>) const;
|
|
|
|
void start_needed_transitions(ComputedProperties const& old_style, ComputedProperties& new_style, DOM::Element&, Optional<Selector::PseudoElement::Type>) const;
|
|
|
|
void resolve_effective_overflow_values(ComputedProperties&) const;
|
|
|
|
void transform_box_type_if_needed(ComputedProperties&, DOM::Element const&, Optional<CSS::Selector::PseudoElement::Type>) const;
|
2021-09-23 13:13:51 +02:00
|
|
|
|
2024-12-20 11:32:17 +01:00
|
|
|
void compute_defaulted_property_value(ComputedProperties&, DOM::Element const*, CSS::PropertyID, Optional<CSS::Selector::PseudoElement::Type>) const;
|
2021-09-21 11:38:18 +02:00
|
|
|
|
LibWeb: Split StyleComputer work into two phases with separate outputs
Before this change, StyleComputer would essentially take a DOM element,
find all the CSS rules that apply to it, and resolve the computed value
for each CSS property for that element.
This worked great, but it meant we had to do all the work of selector
matching and cascading every time.
To enable new optimizations, this change introduces a break in the
middle of this process where we've produced a "CascadedProperties".
This object contains the result of the cascade, before we've begun
turning cascaded values into computed values.
The cascaded properties are now stored with each element, which will
later allow us to do partial updates without re-running the full
StyleComputer machine. This will be particularly valuable for
re-implementing CSS inheritance, which is extremely heavy today.
Note that CSS animations and CSS transitions operate entirely on the
computed values, even though the cascade order would have you believe
they happen earlier. I'm not confident we have the right architecture
for this, but that's a separate issue.
2024-12-12 10:06:29 +01:00
|
|
|
void set_all_properties(
|
|
|
|
CascadedProperties&,
|
|
|
|
DOM::Element&,
|
|
|
|
Optional<Selector::PseudoElement::Type>,
|
|
|
|
CSSStyleValue const&,
|
|
|
|
DOM::Document&,
|
|
|
|
GC::Ptr<CSSStyleDeclaration const>,
|
|
|
|
CascadeOrigin,
|
|
|
|
Important,
|
|
|
|
Optional<FlyString> layer_name) const;
|
2023-07-29 10:53:24 +02:00
|
|
|
|
2019-10-05 09:01:12 +02:00
|
|
|
template<typename Callback>
|
2021-09-21 11:38:18 +02:00
|
|
|
void for_each_stylesheet(CascadeOrigin, Callback) const;
|
|
|
|
|
2024-01-11 14:04:18 +01:00
|
|
|
[[nodiscard]] CSSPixelRect viewport_rect() const { return m_viewport_rect; }
|
|
|
|
|
2024-12-20 11:32:17 +01:00
|
|
|
[[nodiscard]] Length::FontMetrics calculate_root_element_font_metrics(ComputedProperties const&) const;
|
2022-03-19 18:08:52 +01:00
|
|
|
|
2024-09-04 17:43:18 +01:00
|
|
|
Vector<FlyString> m_qualified_layer_names_in_order;
|
|
|
|
void build_qualified_layer_names_cache();
|
|
|
|
|
|
|
|
struct LayerMatchingRules {
|
|
|
|
FlyString qualified_layer_name;
|
2025-01-24 15:47:42 +01:00
|
|
|
Vector<MatchingRule const*> rules;
|
2024-09-04 17:43:18 +01:00
|
|
|
};
|
|
|
|
|
2021-09-21 11:38:18 +02:00
|
|
|
struct MatchingRuleSet {
|
2025-01-24 15:47:42 +01:00
|
|
|
Vector<MatchingRule const*> user_agent_rules;
|
|
|
|
Vector<MatchingRule const*> user_rules;
|
2024-09-04 17:43:18 +01:00
|
|
|
Vector<LayerMatchingRules> author_rules;
|
2021-09-21 11:38:18 +02:00
|
|
|
};
|
|
|
|
|
LibWeb: Split StyleComputer work into two phases with separate outputs
Before this change, StyleComputer would essentially take a DOM element,
find all the CSS rules that apply to it, and resolve the computed value
for each CSS property for that element.
This worked great, but it meant we had to do all the work of selector
matching and cascading every time.
To enable new optimizations, this change introduces a break in the
middle of this process where we've produced a "CascadedProperties".
This object contains the result of the cascade, before we've begun
turning cascaded values into computed values.
The cascaded properties are now stored with each element, which will
later allow us to do partial updates without re-running the full
StyleComputer machine. This will be particularly valuable for
re-implementing CSS inheritance, which is extremely heavy today.
Note that CSS animations and CSS transitions operate entirely on the
computed values, even though the cascade order would have you believe
they happen earlier. I'm not confident we have the right architecture
for this, but that's a separate issue.
2024-12-12 10:06:29 +01:00
|
|
|
void cascade_declarations(
|
|
|
|
CascadedProperties&,
|
|
|
|
DOM::Element&,
|
|
|
|
Optional<CSS::Selector::PseudoElement::Type>,
|
2025-01-24 15:47:42 +01:00
|
|
|
Vector<MatchingRule const*> const&,
|
LibWeb: Split StyleComputer work into two phases with separate outputs
Before this change, StyleComputer would essentially take a DOM element,
find all the CSS rules that apply to it, and resolve the computed value
for each CSS property for that element.
This worked great, but it meant we had to do all the work of selector
matching and cascading every time.
To enable new optimizations, this change introduces a break in the
middle of this process where we've produced a "CascadedProperties".
This object contains the result of the cascade, before we've begun
turning cascaded values into computed values.
The cascaded properties are now stored with each element, which will
later allow us to do partial updates without re-running the full
StyleComputer machine. This will be particularly valuable for
re-implementing CSS inheritance, which is extremely heavy today.
Note that CSS animations and CSS transitions operate entirely on the
computed values, even though the cascade order would have you believe
they happen earlier. I'm not confident we have the right architecture
for this, but that's a separate issue.
2024-12-12 10:06:29 +01:00
|
|
|
CascadeOrigin,
|
|
|
|
Important,
|
|
|
|
Optional<FlyString> layer_name) const;
|
2019-10-05 09:01:12 +02:00
|
|
|
|
2022-02-10 17:49:50 +01:00
|
|
|
void build_rule_cache();
|
|
|
|
void build_rule_cache_if_needed() const;
|
|
|
|
|
2024-11-15 04:01:23 +13:00
|
|
|
GC::Ref<DOM::Document> m_document;
|
2022-02-10 17:49:50 +01:00
|
|
|
|
2024-12-23 15:22:10 +01:00
|
|
|
struct SelectorInsights {
|
|
|
|
bool has_has_selectors { false };
|
|
|
|
};
|
|
|
|
|
2022-02-10 17:49:50 +01:00
|
|
|
struct RuleCache {
|
2023-02-17 14:19:16 +00:00
|
|
|
HashMap<FlyString, Vector<MatchingRule>> rules_by_id;
|
|
|
|
HashMap<FlyString, Vector<MatchingRule>> rules_by_class;
|
|
|
|
HashMap<FlyString, Vector<MatchingRule>> rules_by_tag_name;
|
2024-03-16 08:46:54 +01:00
|
|
|
HashMap<FlyString, Vector<MatchingRule>, AK::ASCIICaseInsensitiveFlyStringTraits> rules_by_attribute_name;
|
2024-09-10 15:18:29 +02:00
|
|
|
Array<Vector<MatchingRule>, to_underlying(CSS::Selector::PseudoElement::Type::KnownPseudoElementCount)> rules_by_pseudo_element;
|
2024-03-13 11:47:25 +01:00
|
|
|
Vector<MatchingRule> root_rules;
|
2022-02-10 17:49:50 +01:00
|
|
|
Vector<MatchingRule> other_rules;
|
2023-05-26 23:30:54 +03:30
|
|
|
|
2024-02-22 13:56:15 +00:00
|
|
|
HashMap<FlyString, NonnullRefPtr<Animations::KeyframeEffect::KeyFrameSet>> rules_by_animation_keyframes;
|
2022-02-10 17:49:50 +01:00
|
|
|
};
|
2023-03-07 20:13:13 +01:00
|
|
|
|
2025-01-27 18:28:48 +01:00
|
|
|
struct RuleCaches {
|
|
|
|
RuleCache main;
|
|
|
|
HashMap<FlyString, NonnullOwnPtr<RuleCache>> by_layer;
|
2025-01-24 10:27:52 +01:00
|
|
|
};
|
2023-03-07 20:13:13 +01:00
|
|
|
|
2025-01-27 18:28:48 +01:00
|
|
|
struct RuleCachesForDocumentAndShadowRoots {
|
|
|
|
RuleCaches for_document;
|
|
|
|
HashMap<GC::Ref<DOM::ShadowRoot const>, NonnullOwnPtr<RuleCaches>> for_shadow_roots;
|
|
|
|
};
|
|
|
|
|
|
|
|
void make_rule_cache_for_cascade_origin(CascadeOrigin, SelectorInsights&, Vector<MatchingRule>& hover_rules);
|
|
|
|
|
|
|
|
[[nodiscard]] RuleCache const* rule_cache_for_cascade_origin(CascadeOrigin, FlyString const& qualified_layer_name, GC::Ptr<DOM::ShadowRoot const>) const;
|
2023-03-07 20:13:13 +01:00
|
|
|
|
2024-12-23 15:22:10 +01:00
|
|
|
static void collect_selector_insights(Selector const&, SelectorInsights&);
|
|
|
|
|
|
|
|
OwnPtr<SelectorInsights> m_selector_insights;
|
2025-01-04 18:09:21 +03:00
|
|
|
Vector<MatchingRule> m_hover_rules;
|
2025-01-12 18:38:05 +03:00
|
|
|
OwnPtr<StyleInvalidationData> m_style_invalidation_data;
|
2025-01-27 18:28:48 +01:00
|
|
|
OwnPtr<RuleCachesForDocumentAndShadowRoots> m_author_rule_cache;
|
|
|
|
OwnPtr<RuleCachesForDocumentAndShadowRoots> m_user_rule_cache;
|
|
|
|
OwnPtr<RuleCachesForDocumentAndShadowRoots> m_user_agent_rule_cache;
|
2024-11-15 04:01:23 +13:00
|
|
|
GC::Root<CSSStyleSheet> m_user_style_sheet;
|
2022-03-29 02:14:20 +02:00
|
|
|
|
2023-12-09 23:42:02 +01:00
|
|
|
using FontLoaderList = Vector<NonnullOwnPtr<FontLoader>>;
|
2024-10-26 23:35:58 +02:00
|
|
|
HashMap<OwnFontFaceKey, FontLoaderList> m_loaded_fonts;
|
2023-05-08 10:28:21 +02:00
|
|
|
|
|
|
|
Length::FontMetrics m_default_font_metrics;
|
|
|
|
Length::FontMetrics m_root_element_font_metrics;
|
2023-05-26 23:30:54 +03:30
|
|
|
|
2024-01-11 14:04:18 +01:00
|
|
|
CSSPixelRect m_viewport_rect;
|
LibWeb: Use an ancestor filter to quickly reject many CSS selectors
Given a selector like `.foo .bar #baz`, we know that elements with
the class names `foo` and `bar` must be present in the ancestor chain of
the candidate element, or the selector cannot match.
By keeping track of the current ancestor chain during style computation,
and which strings are used in tag names and attribute names, we can do
a quick check before evaluating the selector itself, to see if all the
required ancestors are present.
The way this works:
1. CSS::Selector now has a cache of up to 8 strings that must be present
in the ancestor chain of a matching element. Note that we actually
store string *hashes*, not the strings themselves.
2. When Document performs a recursive style update, we now push and pop
elements to the ancestor chain stack as they are entered and exited.
3. When entering/exiting an ancestor, StyleComputer collects all the
relevant string hashes from that ancestor element and updates a
counting bloom filter.
4. Before evaluating a selector, we first check if any of the hashes
required by the selector are definitely missing from the ancestor
filter. If so, it cannot be a match, and we reject it immediately.
5. Otherwise, we carry on and evaluate the selector as usual.
I originally tried doing this with a HashMap, but we ended up losing
a huge chunk of the time saved to HashMap instead. As it turns out,
a simple counting bloom filter is way better at handling this.
The cost is a flat 8KB per StyleComputer, and since it's a bloom filter,
false positives are a thing.
This is extremely efficient, and allows us to quickly reject the
majority of selectors on many huge websites.
Some example rejection rates:
- https://amazon.com: 77%
- https://github.com/SerenityOS/serenity: 61%
- https://nytimes.com: 57%
- https://store.steampowered.com: 55%
- https://en.wikipedia.org: 45%
- https://youtube.com: 32%
- https://shopify.com: 25%
This also yields a chunky 37% speedup on StyleBench. :^)
2024-03-22 13:50:33 +01:00
|
|
|
|
|
|
|
CountingBloomFilter<u8, 14> m_ancestor_filter;
|
2019-06-27 17:47:59 +02:00
|
|
|
};
|
2020-03-07 10:27:02 +01:00
|
|
|
|
2024-05-15 14:58:24 -06:00
|
|
|
class FontLoader : public ResourceClient {
|
|
|
|
public:
|
2024-05-17 17:14:06 -07:00
|
|
|
FontLoader(StyleComputer& style_computer, FlyString family_name, Vector<Gfx::UnicodeRange> unicode_ranges, Vector<URL::URL> urls, ESCAPING Function<void(FontLoader const&)> on_load = {}, ESCAPING Function<void()> on_fail = {});
|
2024-05-15 14:58:24 -06:00
|
|
|
|
|
|
|
virtual ~FontLoader() override;
|
|
|
|
|
|
|
|
Vector<Gfx::UnicodeRange> const& unicode_ranges() const { return m_unicode_ranges; }
|
2024-06-28 20:27:00 +02:00
|
|
|
RefPtr<Gfx::Typeface> vector_font() const { return m_vector_font; }
|
2024-05-15 14:58:24 -06:00
|
|
|
|
|
|
|
RefPtr<Gfx::Font> font_with_point_size(float point_size);
|
|
|
|
void start_loading_next_url();
|
|
|
|
|
2024-09-29 23:38:49 +02:00
|
|
|
bool is_loading() const { return resource() && resource()->is_pending(); }
|
|
|
|
|
2024-05-15 14:58:24 -06:00
|
|
|
private:
|
2024-09-21 18:35:31 +02:00
|
|
|
// ^ResourceClient
|
|
|
|
virtual void resource_did_load() override;
|
|
|
|
virtual void resource_did_fail() override;
|
|
|
|
|
|
|
|
void resource_did_load_or_fail();
|
|
|
|
|
2024-06-28 20:27:00 +02:00
|
|
|
ErrorOr<NonnullRefPtr<Gfx::Typeface>> try_load_font();
|
2024-05-15 14:58:24 -06:00
|
|
|
|
|
|
|
StyleComputer& m_style_computer;
|
|
|
|
FlyString m_family_name;
|
|
|
|
Vector<Gfx::UnicodeRange> m_unicode_ranges;
|
2024-06-28 20:27:00 +02:00
|
|
|
RefPtr<Gfx::Typeface> m_vector_font;
|
2024-05-15 14:58:24 -06:00
|
|
|
Vector<URL::URL> m_urls;
|
|
|
|
Function<void(FontLoader const&)> m_on_load;
|
|
|
|
Function<void()> m_on_fail;
|
|
|
|
};
|
|
|
|
|
2020-03-07 10:27:02 +01:00
|
|
|
}
|