Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-20 16:13:21 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Painting/SVGGraphicsPaintable.cpp

33 lines
884 B
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) 2018-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
*/
#include <LibWeb/Layout/ImageBox.h>
LibWeb: Paint/apply uses of SVG `<clipPath>`s This works just like masks, with a few more (spec imposed) limitations. All the style properties on the contents of a <clipPath> are ignored, and instead we just paint the "raw geometry" (as all black), then apply that as an alpha mask to the target element. If the element has both a `mask` and `clip-path` set, we compute the masking area as the intersection of the mask rect and clip rect, then apply the clip mask to the `mask` (producing a combined mask). Fixes #19648 Fixes #23006
2024-03-27 00:19:41 +00:00
#include <LibWeb/Layout/SVGClipBox.h>
LibWeb: Special case SVG masks during layout Rather than try to lay out masks normally, this updates the TreeBuilder to create layout nodes for masks as a child of their user (i.e. the masked element). This allows each use of a mask to be laid out differently, which makes supporting `maskContentUnits=objectBoundingBox` fairly easy. The `SVGFormattingContext` is then updated to lay out masks last (as their sizing may depend on their parent), and treats them like viewports. This is pretty ad-hoc, but the SVG specification does not give any guidance on how to actually implement this.
2024-03-11 18:26:58 +00:00
#include <LibWeb/Layout/SVGMaskBox.h>
LibWeb: Paint/apply uses of SVG `<clipPath>`s This works just like masks, with a few more (spec imposed) limitations. All the style properties on the contents of a <clipPath> are ignored, and instead we just paint the "raw geometry" (as all black), then apply that as an alpha mask to the target element. If the element has both a `mask` and `clip-path` set, we compute the masking area as the intersection of the mask rect and clip rect, then apply the clip mask to the `mask` (producing a combined mask). Fixes #19648 Fixes #23006
2024-03-27 00:19:41 +00:00
#include <LibWeb/Painting/SVGClipPaintable.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>
LibWeb: Resolve and paint simple SVG masks This allows applying SVG <mask>s to elements. It is only implemented for the simplest (and default) case: - mask-type = luminance - maskContentUnits = maskContentUnits - maskUnits = objectBoundingBox - Default masking area It should be possible to extend to cover more cases. Though the layout for maskContentUnits = objectBoundingBox will be tricky to figure out.
2023-09-10 14:10:55 +01:00
#include <LibWeb/Painting/StackingContext.h>
LibWeb: Add basic support for maskUnits=userSpaceOnUse This still does not use the x, y, width, or height attributes on the mask, but this allows at least displaying these masks.
2023-10-07 20:23:52 +01:00
#include <LibWeb/SVG/SVGSVGElement.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
namespace Web::Painting {
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::Ref<SVGGraphicsPaintable> SVGGraphicsPaintable::create(Layout::SVGGraphicsBox const& layout_box)
LibWeb: Make SVG <g> elements generate a SVGGraphicsPaintable ...instead of defaulting to a PaintableBox. This way it gets the same behavior as other SVG boxes during paint.
2023-04-18 18:56:06 +02:00
{
LibJS+LibWeb: Rename Heap::allocate_without_realm to Heap::allocate Now that the heap has no knowledge about a JavaScript realm and is purely for managing the memory of the heap, it does not make sense to name this function to say that it is a non-realm variant.
2024-11-14 06:13:46 +13:00
return layout_box.heap().allocate<SVGGraphicsPaintable>(layout_box);
LibWeb: Make SVG <g> elements generate a SVGGraphicsPaintable ...instead of defaulting to a PaintableBox. This way it gets the same behavior as other SVG boxes during paint.
2023-04-18 18:56:06 +02: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
SVGGraphicsPaintable::SVGGraphicsPaintable(Layout::SVGGraphicsBox const& layout_box)
: SVGPaintable(layout_box)
{
}
Layout::SVGGraphicsBox const& SVGGraphicsPaintable::layout_box() 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
return static_cast<Layout::SVGGraphicsBox const&>(layout_node());
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