Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Painting/Paintable.h

199 lines
6.7 KiB
C
Raw Normal View History

LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2022-2023, Andreas Kling <andreas@ladybird.org>
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/NonnullOwnPtr.h>
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
#include <LibGC/Root.h>
LibWeb: Invalidate the display list when calling `set_needs_display()` Calls to `Document::set_needs_display()` and `Paintable::set_needs_display()` now invalidate the display list by default. This behavior can be changed by passing `InvalidateDisplayList::No` to the function where invalidating the display list is not necessary.
2024-09-02 16:47:32 +01:00
#include <LibWeb/InvalidateDisplayList.h>
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
#include <LibWeb/Layout/LineBox.h>
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
#include <LibWeb/TraversalDecision.h>
#include <LibWeb/TreeNode.h>
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
namespace Web::Painting {
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
enum class PaintPhase {
Background,
Border,
LibWeb: Apply scroll offset and clip rectangle to table borders Moves paint_table_borders() call into PaintableBox::paint() to make scroll offset and clip rectangle of enclosing scrollable be applied in ::before_paint().
2024-07-30 13:41:48 +03:00
TableCollapsedBorder,
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
Foreground,
LibWeb: Rename PaintPhase::FocusOutline -> Outline Any element can have an outline, whether because of focus or not.
2023-08-02 13:58:34 +01:00
Outline,
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
Overlay,
};
struct HitTestResult {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Root<Paintable> paintable;
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
int index_in_node { 0 };
LibWeb: Pick the closest hit test result, instead of the first When performing a hit test of type TextCursor, it would check if the position is around each fragment and not just inside it. This resulted in always selecting the first fragment checked. This commit computes the distance of each hit test result, and picks the closest one.
2024-07-11 20:12:51 +01:00
Optional<CSSPixels> vertical_distance {};
Optional<CSSPixels> horizontal_distance {};
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
enum InternalPosition {
None,
Before,
Inside,
After,
};
InternalPosition internal_position { None };
LibWeb: Add Painting::HitTestResult::dom_node() This is a convenience accessor to avoid having to say this everywhere: result.paintable->layout_node().dom_node() Instead, you can now do: result.dom_node()
2022-03-21 11:16:02 +01:00
DOM::Node* dom_node();
DOM::Node const* dom_node() const;
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
};
enum class HitTestType {
Exact, // Exact matches only
TextCursor, // Clicking past the right/bottom edge of text will still hit the text
};
LibWeb: Make the paint tree a proper standalone tree Until now, paint trees have been piggybacking on the layout tree for traversal, and paintables didn't actually have their own parent/child pointers. This patch changes that by making Paintable inherit from TreeNode, and adding a new pass to LayoutState::commit() where we recursively build the new paint tree.
2023-08-18 12:30:27 +02:00
class Paintable
: public JS::Cell
, public TreeNode<Paintable> {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_CELL(Paintable, JS::Cell);
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
public:
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 02:40:31 +01:00
virtual ~Paintable();
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
LibWeb: Remove cache for Paintable::is_visible() ...because it depends on computed values that could be changed without rebuilding paintable tree.
2024-03-25 12:23:42 +01:00
[[nodiscard]] bool is_visible() const;
LibWeb: Copy various flags from layout node to paintable This removes indirection when asking if a paintable is positioned, floating, etc. Removes a bunch of 1-1.5% items in the profile when hovering links on ziglang.org.
2024-03-02 11:03:02 +01:00
[[nodiscard]] bool is_positioned() const { return m_positioned; }
[[nodiscard]] bool is_fixed_position() const { return m_fixed_position; }
LibWeb: Add "position: sticky" support Sticky positioning is implemented by modifying the algorithm for assigning and refreshing scroll frames. Now, elements with "position: sticky" are assigned their own scroll frame, and their position is refreshed independently from regular scroll boxes. Refreshing the scroll offsets for sticky boxes does not require display list invalidation. A separate hash map is used for the scroll frames of sticky boxes. This is necessary because a single paintable box can have two scroll frames if it 1) has "position: sticky" and 2) contains scrollable overflow.
2024-08-24 19:20:31 +02:00
[[nodiscard]] bool is_sticky_position() const { return m_sticky_position; }
LibWeb: Copy various flags from layout node to paintable This removes indirection when asking if a paintable is positioned, floating, etc. Removes a bunch of 1-1.5% items in the profile when hovering links on ziglang.org.
2024-03-02 11:03:02 +01:00
[[nodiscard]] bool is_absolutely_positioned() const { return m_absolutely_positioned; }
[[nodiscard]] bool is_floating() const { return m_floating; }
[[nodiscard]] bool is_inline() const { return m_inline; }
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
[[nodiscard]] CSS::Display display() const;
LibWeb: Make StackingContext point to paint tree instead of layout tree Eventually we should not need the layout tree for anything when painting and this code will only look at the paint tree. For now, this is just another step in that direction.
2023-08-19 15:20:45 +02:00
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
bool has_stacking_context() const;
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 02:40:31 +01:00
StackingContext* enclosing_stacking_context();
LibWeb: Apply CSS `clip` property to an element as well as its children d06d4eb made the `clip` property apply to children of an absolute- positioned element, but caused it not to be applied to the element the property was applied to directly. To fix this, apply the clip in new `before_paint()` and `after_paint()` functions. Doing so keeps painter state from leaking from `paint()`, but still allows subclasses of `PaintableBox` clip their contents correctly without repeating the application of the clip rectangle.
2023-08-31 17:08:45 -05:00
virtual void before_paint(PaintContext&, PaintPhase) const { }
virtual void after_paint(PaintContext&, PaintPhase) const { }
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
virtual void paint(PaintContext&, PaintPhase) const { }
LibWeb: Don't clip to containing block when painting abspos descendants
2022-09-13 20:45:38 +02:00
LibWeb: Clip hidden overflow by absolute rect of containing block Since handling overflow: hidden in PaintableBox::before_children_paint while following paint traversal order can't result in correctly computed clip rectangle for elements that create their own stacking context (because before_children_paint is called only for parent but overflow: hidden can be set somewhere deeper but not in direct ancestor), here introduced new function PaintableBox::clip_rect() that computes clip rectangle by looking into containing block. should_clip_overflow flag that disables clip for absolutely positioned elements in before_children_paint and after_children_paint is removed because after changing clip rectangle to be computed from not parent but containing block it is not needed anymore (absolutely positioned item is clipped if it's containing block has hidden overflow)
2022-11-12 00:07:43 +03:00
virtual void before_children_paint(PaintContext&, PaintPhase) const { }
virtual void after_children_paint(PaintContext&, PaintPhase) const { }
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
LibWeb: Add pair of methods to apply/reset scroll offset of paintable Separate scroll application from before_children_paint and after_children_paint.
2023-12-11 16:47:40 +01:00
virtual void apply_scroll_offset(PaintContext&, PaintPhase) const { }
virtual void reset_scroll_offset(PaintContext&, PaintPhase) const { }
LibWeb: Use rect of containing block instead of parent to clip overflow Move overflow clipping from `before_children_paint` into separate method and call this method on containing block instead of parent. Example that got fixed: ```html <!DOCTYPE html><html><head><style> * { border: 2px solid black; } body { overflow: hidden; } .inner { position: absolute; width: 100px; height: 100px; background: lime; } </style></head><body><div class=inner></div> ```
2023-01-25 04:50:14 +03:00
virtual void apply_clip_overflow_rect(PaintContext&, PaintPhase) const { }
virtual void clear_clip_overflow_rect(PaintContext&, PaintPhase) const { }
LibWeb: Change StackingContext::hit_test() to accept callback This change modifies hit_test() to no longer return the first paintable encountered at a specified position. Instead, this function accepts a callback that is invoked for each paintable located at a position, in hit-testing order. This modification will allow us to reuse this call for `Document.elementsFromPoint()` in upcoming changes.
2024-02-13 21:34:07 +01:00
[[nodiscard]] virtual TraversalDecision hit_test(CSSPixelPoint, HitTestType, Function<TraversalDecision(HitTestResult)> const& callback) const;
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
virtual bool wants_mouse_events() const { return false; }
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) This commit is messy due to the Paintable and Layout classes being tangled together. The RadioButton, CheckBox and ButtonBox classes are now subclasses of FormAssociatedLabelableNode. This subclass separates these layout nodes from LabelableNode, which is also the superclass of non-form associated labelable nodes (Progress). ButtonPaintable, CheckBoxPaintable and RadioButtonPaintable no longer call events on DOM nodes directly from their mouse event handlers; instead, all the functionality is now directly in EventHandler, which dispatches the related events. handle_mousedown and related methods return a bool indicating whether the event handling should proceed. Paintable classes can now return an alternative DOM::Node which should be the target of the mouse event. Labels use this to indicate that the labeled control should be the target of the mouse events. HTMLInputElement put its activation behavior on run_activation_behavior, which wasn't actually called anywhere and had to be manually called by other places. We now use activation_behavior which is used by EventDispatcher. This commit also brings HTMLInputElement closer to spec by removing the did_foo functions that did ad-hoc event dispatching and unifies the behavior under run_input_activation_behavior.
2022-03-14 23:05:55 +00:00
LibWeb: Layout SVG <mask> elements (but don't paint them) This allows SVG mask elements to have layout computed, but not connected to the main paint tree. They should only be reachable if (and painted) if referenced by the "mask" attribute of another element. This is controlled by the forms_unconnected_subtree() function on the paintable, which (if it returns true) prevents the paintable from being added as a child to what would be its parent.
2023-09-17 15:32:24 +01:00
virtual bool forms_unconnected_subtree() const { return false; }
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) This commit is messy due to the Paintable and Layout classes being tangled together. The RadioButton, CheckBox and ButtonBox classes are now subclasses of FormAssociatedLabelableNode. This subclass separates these layout nodes from LabelableNode, which is also the superclass of non-form associated labelable nodes (Progress). ButtonPaintable, CheckBoxPaintable and RadioButtonPaintable no longer call events on DOM nodes directly from their mouse event handlers; instead, all the functionality is now directly in EventHandler, which dispatches the related events. handle_mousedown and related methods return a bool indicating whether the event handling should proceed. Paintable classes can now return an alternative DOM::Node which should be the target of the mouse event. Labels use this to indicate that the labeled control should be the target of the mouse events. HTMLInputElement put its activation behavior on run_activation_behavior, which wasn't actually called anywhere and had to be manually called by other places. We now use activation_behavior which is used by EventDispatcher. This commit also brings HTMLInputElement closer to spec by removing the did_foo functions that did ad-hoc event dispatching and unifies the behavior under run_input_activation_behavior.
2022-03-14 23:05:55 +00:00
enum class DispatchEventOfSameName {
Yes,
No,
};
// When these methods return true, the DOM event with the same name will be
// dispatch at the mouse_event_target if it returns a valid DOM::Node, or
// the layout node's associated DOM node if it doesn't.
LibWeb+WebContent+headless-browser: Use CSSPixels for PageClient events ...and also for hit testing, which is involved in most of them. Much of this is temporary conversions and other awkwardness, which should resolve itself as the rest of LibWeb is converted to these new types. Hopefully. :thousandyakstare:
2022-11-02 17:35:53 +00:00
virtual DispatchEventOfSameName handle_mousedown(Badge<EventHandler>, CSSPixelPoint, unsigned button, unsigned modifiers);
virtual DispatchEventOfSameName handle_mouseup(Badge<EventHandler>, CSSPixelPoint, unsigned button, unsigned modifiers);
virtual DispatchEventOfSameName handle_mousemove(Badge<EventHandler>, CSSPixelPoint, unsigned buttons, unsigned modifiers);
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) This commit is messy due to the Paintable and Layout classes being tangled together. The RadioButton, CheckBox and ButtonBox classes are now subclasses of FormAssociatedLabelableNode. This subclass separates these layout nodes from LabelableNode, which is also the superclass of non-form associated labelable nodes (Progress). ButtonPaintable, CheckBoxPaintable and RadioButtonPaintable no longer call events on DOM nodes directly from their mouse event handlers; instead, all the functionality is now directly in EventHandler, which dispatches the related events. handle_mousedown and related methods return a bool indicating whether the event handling should proceed. Paintable classes can now return an alternative DOM::Node which should be the target of the mouse event. Labels use this to indicate that the labeled control should be the target of the mouse events. HTMLInputElement put its activation behavior on run_activation_behavior, which wasn't actually called anywhere and had to be manually called by other places. We now use activation_behavior which is used by EventDispatcher. This commit also brings HTMLInputElement closer to spec by removing the did_foo functions that did ad-hoc event dispatching and unifies the behavior under run_input_activation_behavior.
2022-03-14 23:05:55 +00:00
LibWeb+WebContent+headless-browser: Use CSSPixels for PageClient events ...and also for hit testing, which is involved in most of them. Much of this is temporary conversions and other awkwardness, which should resolve itself as the rest of LibWeb is converted to these new types. Hopefully. :thousandyakstare:
2022-11-02 17:35:53 +00:00
virtual bool handle_mousewheel(Badge<EventHandler>, CSSPixelPoint, unsigned buttons, unsigned modifiers, int wheel_delta_x, int wheel_delta_y);
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
Layout::Node const& layout_node() const { return m_layout_node; }
LibWeb: Make the paint tree GC-allocated This simplifies the ownership model between DOM/layout/paint nodes immensely by deferring to the garbage collector for figuring out what's live and what's not.
2023-01-11 12:51:49 +01:00
Layout::Node& layout_node() { return const_cast<Layout::Node&>(*m_layout_node); }
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
[[nodiscard]] GC::Ptr<DOM::Node> dom_node();
[[nodiscard]] GC::Ptr<DOM::Node const> dom_node() const;
void set_dom_node(GC::Ptr<DOM::Node>);
LibWeb: Add Paintable::dom_node() convenience accessor
2022-03-21 11:19:02 +01:00
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
CSS::ImmutableComputedValues const& computed_values() const;
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
LibWeb: Ensure inert elements are not visible for hit testing
2025-02-05 23:37:21 +00:00
bool visible_for_hit_testing() const;
LibWeb: Fix pointer-events check in hit_test
2022-10-20 01:43:31 +03:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<HTML::Navigable> navigable() const;
LibWeb: Move set_needs_display() from layout node to paintable For this method, there is no need to go through the layout node when we can directly reach the paintable.
2024-01-14 13:46:52 +01:00
LibWeb: Invalidate the display list when calling `set_needs_display()` Calls to `Document::set_needs_display()` and `Paintable::set_needs_display()` now invalidate the display list by default. This behavior can be changed by passing `InvalidateDisplayList::No` to the function where invalidating the display list is not necessary.
2024-09-02 16:47:32 +01:00
virtual void set_needs_display(InvalidateDisplayList = InvalidateDisplayList::Yes);
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
PaintableBox* containing_block() const;
LibWeb: Let paintables cache their containing block and absolute rect The absolute rect of a paintable is somewhat expensive to compute. This is because all coordinates are relative to the nearest containing block, so we have to traverse the containing block chain and apply each offset to get the final rect. Paintables will never move between containing blocks, nor will their absolute rect change. If anything changes, we'll simpl make a new paintable and replace the old one. Take advantage of this by caching the containing block and absolute rect after first access.
2022-03-12 00:35:49 +01:00
LibWeb: Add some basic paint tree traversal helpers Give the Paintable class some basic helpers for traversing the paint tree. Note that they actually piggy-back on the layout tree for links between nodes.
2022-04-08 15:19:02 +02:00
template<typename T>
bool fast_is() const = delete;
LibWeb: Add virtuals to check if Paintable is PBox or PWithLines Instead of inferring the type of paintables by looking at the type of their origin in the layout tree, let's ask them directly.
2023-08-18 13:47:52 +02:00
[[nodiscard]] virtual bool is_paintable_box() const { return false; }
[[nodiscard]] virtual bool is_paintable_with_lines() const { return false; }
LibWeb: Add fast_is<T>() for SVGPaintable
2024-03-02 11:17:33 +01:00
[[nodiscard]] virtual bool is_svg_paintable() const { return false; }
LibWeb: Add fast_is<TextPaintable>()
2024-03-18 10:25:07 +01:00
[[nodiscard]] virtual bool is_text_paintable() const { return false; }
LibWeb: Add virtuals to check if Paintable is PBox or PWithLines Instead of inferring the type of paintables by looking at the type of their origin in the layout tree, let's ask them directly.
2023-08-18 13:47:52 +02:00
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
DOM::Document const& document() const;
DOM::Document& document();
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 02:40:31 +01:00
LibWeb: Move box_type_agnostic_position() from layout node to paintable For this method, there is no need to go through the layout node when we can directly reach the paintable.
2024-01-14 11:14:20 +01:00
CSSPixelPoint box_type_agnostic_position() const;
LibWeb: Move selection state from layout tree to paint tree Where we paint the selection is obviously paint-related information, so let's keep it in the paint tree.
2024-03-18 07:42:38 +01:00
enum class SelectionState : u8 {
None, // No selection
Start, // Selection starts in this Node
End, // Selection ends in this Node
StartAndEnd, // Selection starts and ends in this Node
Full, // Selection starts before and ends after this Node
};
SelectionState selection_state() const { return m_selection_state; }
void set_selection_state(SelectionState state) { m_selection_state = state; }
LibWeb: Remove CSS transform from InlinePaintable's clip rectangle Fixes bug when CSS transform is applied twice to clip rect: - While calculating absolute clip rectangles in `refresh_clip_state()` - While executing `PushStackingContext` painting command. Duplicated transform is already removed for PaintableBox and this change adds this for InlinePaintable.
2024-04-26 18:04:15 +02:00
Gfx::AffineTransform compute_combined_css_transform() const;
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
virtual void resolve_paint_properties() { }
virtual void finalize() override
{
if (m_list_node.is_in_list())
m_list_node.remove();
}
friend class Layout::Node;
LibWeb: Separate paint-only property resolution by paintable type Having resolution of all properties for all paintable types in a single function was hard to iterate on, so this change separates it into smaller functions per paintable type.
2024-07-22 18:43:01 +03:00
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
protected:
LibWeb: Give paintables their own pointer to the BrowsingContext
2023-08-18 13:21:38 +02:00
explicit Paintable(Layout::Node const&);
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
LibWeb: Make the paint tree GC-allocated This simplifies the ownership model between DOM/layout/paint nodes immensely by deferring to the garbage collector for figuring out what's live and what's not.
2023-01-11 12:51:49 +01:00
virtual void visit_edges(Cell::Visitor&) override;
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
private:
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
IntrusiveListNode<Paintable> m_list_node;
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<DOM::Node> m_dom_node;
GC::Ref<Layout::Node const> m_layout_node;
Optional<GC::Ptr<PaintableBox>> mutable m_containing_block;
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 02:40:31 +01:00
LibWeb: Move selection state from layout tree to paint tree Where we paint the selection is obviously paint-related information, so let's keep it in the paint tree.
2024-03-18 07:42:38 +01:00
SelectionState m_selection_state { SelectionState::None };
LibWeb: Copy various flags from layout node to paintable This removes indirection when asking if a paintable is positioned, floating, etc. Removes a bunch of 1-1.5% items in the profile when hovering links on ziglang.org.
2024-03-02 11:03:02 +01:00
bool m_positioned : 1 { false };
bool m_fixed_position : 1 { false };
LibWeb: Add "position: sticky" support Sticky positioning is implemented by modifying the algorithm for assigning and refreshing scroll frames. Now, elements with "position: sticky" are assigned their own scroll frame, and their position is refreshed independently from regular scroll boxes. Refreshing the scroll offsets for sticky boxes does not require display list invalidation. A separate hash map is used for the scroll frames of sticky boxes. This is necessary because a single paintable box can have two scroll frames if it 1) has "position: sticky" and 2) contains scrollable overflow.
2024-08-24 19:20:31 +02:00
bool m_sticky_position : 1 { false };
LibWeb: Copy various flags from layout node to paintable This removes indirection when asking if a paintable is positioned, floating, etc. Removes a bunch of 1-1.5% items in the profile when hovering links on ziglang.org.
2024-03-02 11:03:02 +01:00
bool m_absolutely_positioned : 1 { false };
bool m_floating : 1 { false };
bool m_inline : 1 { false };
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
};
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
LibWeb: Add Painting::HitTestResult::dom_node() This is a convenience accessor to avoid having to say this everywhere: result.paintable->layout_node().dom_node() Instead, you can now do: result.dom_node()
2022-03-21 11:16:02 +01:00
inline DOM::Node* HitTestResult::dom_node()
{
LibWeb: Add Paintable::dom_node() convenience accessor
2022-03-21 11:19:02 +01:00
return paintable->dom_node();
LibWeb: Add Painting::HitTestResult::dom_node() This is a convenience accessor to avoid having to say this everywhere: result.paintable->layout_node().dom_node() Instead, you can now do: result.dom_node()
2022-03-21 11:16:02 +01:00
}
inline DOM::Node const* HitTestResult::dom_node() const
{
LibWeb: Add Paintable::dom_node() convenience accessor
2022-03-21 11:19:02 +01:00
return paintable->dom_node();
LibWeb: Add Painting::HitTestResult::dom_node() This is a convenience accessor to avoid having to say this everywhere: result.paintable->layout_node().dom_node() Instead, you can now do: result.dom_node()
2022-03-21 11:16:02 +01:00
}
LibWeb: Add some basic paint tree traversal helpers Give the Paintable class some basic helpers for traversing the paint tree. Note that they actually piggy-back on the layout tree for links between nodes.
2022-04-08 15:19:02 +02:00
template<>
LibWeb: Add virtuals to check if Paintable is PBox or PWithLines Instead of inferring the type of paintables by looking at the type of their origin in the layout tree, let's ask them directly.
2023-08-18 13:47:52 +02:00
inline bool Paintable::fast_is<PaintableBox>() const { return is_paintable_box(); }
template<>
inline bool Paintable::fast_is<PaintableWithLines>() const { return is_paintable_with_lines(); }
LibWeb: Add some basic paint tree traversal helpers Give the Paintable class some basic helpers for traversing the paint tree. Note that they actually piggy-back on the layout tree for links between nodes.
2022-04-08 15:19:02 +02:00
LibWeb: Add fast_is<TextPaintable>()
2024-03-18 10:25:07 +01:00
template<>
inline bool Paintable::fast_is<TextPaintable>() const { return is_text_paintable(); }
LibWeb: Separate paint-only property resolution by paintable type Having resolution of all properties for all paintable types in a single function was hard to iterate on, so this change separates it into smaller functions per paintable type.
2024-07-22 18:43:01 +03:00
Painting::BorderRadiiData normalize_border_radii_data(Layout::Node const& node, CSSPixelRect const& rect, CSS::BorderRadiusData const& top_left_radius, CSS::BorderRadiusData const& top_right_radius, CSS::BorderRadiusData const& bottom_right_radius, CSS::BorderRadiusData const& bottom_left_radius);
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
}
Reference in a new issue Copy permalink