mirrors/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-01-23 17:52:26 -05:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Painting/SVGPathPaintable.h

42 lines
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
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2022, Andreas Kling <andreas@ladybird.org>
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
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
#include <LibGfx/Path.h>
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 {
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(SVGPathPaintable, SVGGraphicsPaintable);
GC_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:
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
static GC::Ref<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
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
void set_computed_path(Gfx::Path 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
}
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
Optional<Gfx::Path> 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
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
Optional<Gfx::Path> 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