Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-01 22:00:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/Painting/SVGPathPaintable.h

41 lines
1.1 KiB
C
Raw Normal View History

LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
/*
* Copyright (c) 2022, Andreas Kling <kling@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibWeb: Support transforms, stroking, gradients, etc for SVG <text> This makes use of the new Gfx::Path::text() to handle SVG text elements, with this text is just a regular path, and can be manipulated like any other graphics element. This removes the SVGTextPaintable and makes both <text> and geometry elements use a new (shared) SVGPathPaintable. This is identical to the old SVGGeometryPaintable. This simplifies painting as once something is resolved to a Gfx::Path, the painting logic is the same.
2023-11-04 21:31:35 +00:00
#include <LibWeb/Layout/SVGGraphicsBox.h>
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
#include <LibWeb/Painting/SVGGraphicsPaintable.h>
namespace Web::Painting {
LibWeb: Support transforms, stroking, gradients, etc for SVG <text> This makes use of the new Gfx::Path::text() to handle SVG text elements, with this text is just a regular path, and can be manipulated like any other graphics element. This removes the SVGTextPaintable and makes both <text> and geometry elements use a new (shared) SVGPathPaintable. This is identical to the old SVGGeometryPaintable. This simplifies painting as once something is resolved to a Gfx::Path, the painting logic is the same.
2023-11-04 21:31:35 +00:00
class SVGPathPaintable final : public SVGGraphicsPaintable {
JS_CELL(SVGPathPaintable, SVGGraphicsPaintable);
LibWeb: Add calls to JS_{DECLARE,DEFINE}_ALLOCATOR()
2024-04-06 10:16:04 -07:00
JS_DECLARE_ALLOCATOR(SVGPathPaintable);
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
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
public:
LibWeb: Support transforms, stroking, gradients, etc for SVG <text> This makes use of the new Gfx::Path::text() to handle SVG text elements, with this text is just a regular path, and can be manipulated like any other graphics element. This removes the SVGTextPaintable and makes both <text> and geometry elements use a new (shared) SVGPathPaintable. This is identical to the old SVGGeometryPaintable. This simplifies painting as once something is resolved to a Gfx::Path, the painting logic is the same.
2023-11-04 21:31:35 +00:00
static JS::NonnullGCPtr<SVGPathPaintable> create(Layout::SVGGraphicsBox const&);
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01: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
virtual TraversalDecision hit_test(CSSPixelPoint, HitTestType, Function<TraversalDecision(HitTestResult)> const& callback) const override;
LibWeb: Use (transformed) path bounding quad for SVG path hit testing This is needed for hit testing the directional arrows on the Street View office tour, and generally makes SVG hit testing more precise. Note: The rough bounding box is hit test first, so this should not be a load more overhead.
2023-04-10 12:35:33 +01:00
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
virtual void paint(PaintContext&, PaintPhase) const override;
LibWeb: Support transforms, stroking, gradients, etc for SVG <text> This makes use of the new Gfx::Path::text() to handle SVG text elements, with this text is just a regular path, and can be manipulated like any other graphics element. This removes the SVGTextPaintable and makes both <text> and geometry elements use a new (shared) SVGPathPaintable. This is identical to the old SVGGeometryPaintable. This simplifies painting as once something is resolved to a Gfx::Path, the painting logic is the same.
2023-11-04 21:31:35 +00:00
Layout::SVGGraphicsBox const& layout_box() const;
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
LibGfx: Rename Path => DeprecatedPath
2024-08-08 10:22:03 +02:00
void set_computed_path(Gfx::DeprecatedPath path)
LibWeb: Store computed SVG path data/transforms in LayoutState This removes the awkward hack to recompute the layout transform at paint time, and makes it possible for path sizes to be computed during layout. For example, it's possible to use relative units in SVG shapes (e.g. <rect>), which can be resolved during layout, but would be hard to resolve again during painting.
2023-10-29 17:08:35 +00:00
{
LibWeb: Layout SVG <text> elements during layout (not while painting) Previously, all SVG <text> elements were zero-sized boxes, that were only actually positioned and sized during painting. This led to a number of problems, the most visible of which being that text could not be scaled based on the viewBox. Which this patch, <text> elements get a correctly sized layout box, that can be hit-tested and respects the SVG viewBox. To share code with SVGGeometryElement's the PathData (from the prior commit) has been split into a computed path and computed transforms. The computed path is specific to geometry elements, but the computed transforms are shared between all SVG graphics elements.
2023-10-29 19:11:46 +00:00
m_computed_path = move(path);
LibWeb: Store computed SVG path data/transforms in LayoutState This removes the awkward hack to recompute the layout transform at paint time, and makes it possible for path sizes to be computed during layout. For example, it's possible to use relative units in SVG shapes (e.g. <rect>), which can be resolved during layout, but would be hard to resolve again during painting.
2023-10-29 17:08:35 +00:00
}
LibGfx: Rename Path => DeprecatedPath
2024-08-08 10:22:03 +02:00
Optional<Gfx::DeprecatedPath> const& computed_path() const { return m_computed_path; }
LibWeb: Store computed SVG path data/transforms in LayoutState This removes the awkward hack to recompute the layout transform at paint time, and makes it possible for path sizes to be computed during layout. For example, it's possible to use relative units in SVG shapes (e.g. <rect>), which can be resolved during layout, but would be hard to resolve again during painting.
2023-10-29 17:08:35 +00:00
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
protected:
LibWeb: Support transforms, stroking, gradients, etc for SVG <text> This makes use of the new Gfx::Path::text() to handle SVG text elements, with this text is just a regular path, and can be manipulated like any other graphics element. This removes the SVGTextPaintable and makes both <text> and geometry elements use a new (shared) SVGPathPaintable. This is identical to the old SVGGeometryPaintable. This simplifies painting as once something is resolved to a Gfx::Path, the painting logic is the same.
2023-11-04 21:31:35 +00:00
SVGPathPaintable(Layout::SVGGraphicsBox const&);
LibWeb: Store computed SVG path data/transforms in LayoutState This removes the awkward hack to recompute the layout transform at paint time, and makes it possible for path sizes to be computed during layout. For example, it's possible to use relative units in SVG shapes (e.g. <rect>), which can be resolved during layout, but would be hard to resolve again during painting.
2023-10-29 17:08:35 +00:00
LibGfx: Rename Path => DeprecatedPath
2024-08-08 10:22:03 +02:00
Optional<Gfx::DeprecatedPath> m_computed_path = {};
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
};
}
Reference in a new issue Copy permalink