Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-12-07 21:59:54 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Painting/Paintable.h

202 lines
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
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: Reduced number of recompiled files for CSS property headers This reduces the number of `.cpp` files that need to be recompiled when one of the below header files changes as follows: CSS/ComputedProperties.h: 1113 -> 49 CSS/ComputedValues.h: 1120 -> 209
2025-02-18 09:19:56 +01:00
#include <LibWeb/CSS/ComputedValues.h>
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
#include <LibWeb/Export.h>
LibWeb: Reduced number of recompiled files for CSS property headers This reduces the number of `.cpp` files that need to be recompiled when one of the below header files changes as follows: CSS/ComputedProperties.h: 1113 -> 49 CSS/ComputedValues.h: 1120 -> 209
2025-02-18 09:19:56 +01:00
#include <LibWeb/Forward.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: Reduce number of recompiled files for display list headers This reduces the number of `.cpp` files that need to be recompiled when one of the below header files changes as follows: Painting/Command.h: 1030 -> 61 Painting/DisplayList.h: 1030 -> 60 Painting/DisplayListRecorder.h: 557 -> 59
2025-02-02 15:55:26 +01:00
#include <LibWeb/PixelUnits.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: Make fragment start/length `size_t` instead of `int` These must always be unsigned. No functional changes.
2025-06-11 09:07:16 +02:00
size_t 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: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
class WEB_API Paintable
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
: 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: More thoroughly detach layout/paint trees from each other Before committing a new layout (and thus building a new paint tree) we now go through both the old paint tree and the layout tree and detach them from each other. This is a little extra work, but it ensures that there are no lingering references across the trees, which we were apparently accumulating in some cases on Discord, causing GC leaks.
2025-07-30 16:57:03 +02:00
void detach_from_layout_node();
Revert "LibWeb: Store visibility for Paintables" This reverts commit 7dc80622832ffb6d82a098c8f3942676f01e4b92. This did not propagate correctly to paintables whose style was inherited from an ancestor, causing rendering artifacts on https://linear.app/
2025-08-19 11:33:29 +02: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: Rename PaintContext to DisplayListRecordingContext PaintContext dates back to a time when display lists didn't exist and it truly represented "paint context". Renaming it to better align with its current role.
2025-07-31 23:07:26 +02:00
virtual void before_paint(DisplayListRecordingContext&, PaintPhase) const { }
virtual void after_paint(DisplayListRecordingContext&, PaintPhase) const { }
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
LibWeb: Rename PaintContext to DisplayListRecordingContext PaintContext dates back to a time when display lists didn't exist and it truly represented "paint context". Renaming it to better align with its current role.
2025-07-31 23:07:26 +02:00
virtual void paint(DisplayListRecordingContext&, PaintPhase) const { }
LibWeb: Paint inspector overlays as a separate pass The overlay shown for the node hovered in the inspector is painted as part of the normal tree traversal of all paintables. This works well in most cases, but falls short in specific scenarios: * If the hovered node or one of its ancestors establishes a stacking context and there is another element that establishes a stacking context close by or overlapping it, the overlay and especially the tooltip can become partially hidden behind the second element. Ditto for elements that act as if they established a stacking context. * If the hovered node or one of its ancestors involves clipping, the clip is applied to the overlay and espicially the tooltip. This can cause them to be partially invisible. * Similarly, if the hovered node or one of its ancestors has a defined mask, the mask is applied to the overlay, often making it mostly invisible. * No overlays are shown for SVG nodes because they are painted differently from HTML documents. Some of these problems may be fixable with the current system. But some seem like they fundamentally cannot work fully when the overlays are painted as part of the regular tree traversal. Instead we pull out painting the overlay as a separate pass executed after the tree traversal. This way we ensure that the overlays are always painted last and therefore on top of everything else. This also makes sure that the overlays are unaffected by clips and masks. And since overlay painting is independent from painting the actual elements, it just works as well. However we need to be careful, because we still need to apply some of the steps of the tree traversal to get the correct result. Namely we need to apply scroll offsets and transforms. To do so, we collect all ancestors of the hovered node and apply those as if we were in the normal tree traversal.
2025-09-02 22:57:41 +02:00
void paint_inspector_overlay(DisplayListRecordingContext&) const;
LibWeb: Don't clip to containing block when painting abspos descendants
2022-09-13 20:45:38 +02:00
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+UI: Add an explicit IPC to handle mouse leave events The faux position we created here is adjusted by the device pixel ratio later on, which would invoke integer overflow on screens with a DPR greater than 1. Instead of creating special data for a mouse move event, let's just add an explicit leave event handler.
2025-07-28 12:57:31 -04:00
virtual void handle_mouseleave(Badge<EventHandler>) { }
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: Fix scroll state refresh in cached display list for iframes 6507d23 introduced a bug when snapshot for iframe is saved in `PaintNestedDisplayList` and, since display lists are immutable, it's not possible to update before the next repaint. This change fixes the issue by moving `ScrollStateSnapshot` for nested display lists from `PaintNestedDisplayList` to `HashMap<NonnullRefPtr<DisplayList>, ScrollStateSnapshot>` that is placed into pending rendering task, making it possible to update snapshots for all display lists before the next repaint. This change doesn't have a test because it's really hard to make a ref test that will specifically check scenario when scroll offset of an iframe is advanced after display list is cached. We already have `Tests/LibWeb/Ref/input/scroll-iframe.html` but unfortunately it did not catch this bug. Fixes https://github.com/LadybirdBrowser/ladybird/issues/5486
2025-07-25 01:39:31 +02:00
[[nodiscard]] virtual bool is_navigable_container_viewport_paintable() const { return false; }
LibWeb: Add fast_is<T> optimization for more paintables We were doing a lot of dynamic_cast with these types, so let's avoid it.
2025-09-21 14:14:39 +02:00
[[nodiscard]] virtual bool is_viewport_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
[[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 more fast_is<T> helpers for layout and paintable nodes
2025-04-18 10:28:46 +02:00
[[nodiscard]] virtual bool is_svg_svg_paintable() const { return false; }
LibWeb: Add fast_is<T> optimization for more paintables We were doing a lot of dynamic_cast with these types, so let's avoid it.
2025-09-21 14:14:39 +02:00
[[nodiscard]] virtual bool is_svg_path_paintable() const { return false; }
[[nodiscard]] virtual bool is_svg_graphics_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: Paint inspector overlays as a separate pass The overlay shown for the node hovered in the inspector is painted as part of the normal tree traversal of all paintables. This works well in most cases, but falls short in specific scenarios: * If the hovered node or one of its ancestors establishes a stacking context and there is another element that establishes a stacking context close by or overlapping it, the overlay and especially the tooltip can become partially hidden behind the second element. Ditto for elements that act as if they established a stacking context. * If the hovered node or one of its ancestors involves clipping, the clip is applied to the overlay and espicially the tooltip. This can cause them to be partially invisible. * Similarly, if the hovered node or one of its ancestors has a defined mask, the mask is applied to the overlay, often making it mostly invisible. * No overlays are shown for SVG nodes because they are painted differently from HTML documents. Some of these problems may be fixable with the current system. But some seem like they fundamentally cannot work fully when the overlays are painted as part of the regular tree traversal. Instead we pull out painting the overlay as a separate pass executed after the tree traversal. This way we ensure that the overlays are always painted last and therefore on top of everything else. This also makes sure that the overlays are unaffected by clips and masks. And since overlay painting is independent from painting the actual elements, it just works as well. However we need to be careful, because we still need to apply some of the steps of the tree traversal to get the correct result. Namely we need to apply scroll offsets and transforms. To do so, we collect all ancestors of the hovered node and apply those as if we were in the normal tree traversal.
2025-09-02 22:57:41 +02:00
virtual void paint_inspector_overlay_internal(DisplayListRecordingContext&) const { }
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 };
LibGC+LibWeb+LibJS: Remove workaround for Swift boolean bitfield issue We're using a main snapshot everywhere, so we can yeet the workaround.
2025-04-04 07:04:10 -06:00
bool m_positioned : 1 { false };
bool m_fixed_position : 1 { false };
bool m_sticky_position : 1 { false };
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: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
WEB_API 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: 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: 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