ladybird/Libraries/LibWeb/Painting/SVGMaskPaintable.cpp

/*
 * Copyright (c) 2024, MacDue <macdue@dueutil.tech>
 *
 * SPDX-License-Identifier: BSD-2-Clause
 */

#include <LibWeb/Painting/SVGMaskPaintable.h>

namespace Web::Painting {

GC_DEFINE_ALLOCATOR(SVGMaskPaintable);

GC::Ref<SVGMaskPaintable> SVGMaskPaintable::create(Layout::SVGMaskBox const& layout_box)
{
    return layout_box.heap().allocate<SVGMaskPaintable>(layout_box);
}

SVGMaskPaintable::SVGMaskPaintable(Layout::SVGMaskBox const& layout_box)
    : SVGGraphicsPaintable(layout_box)
{
}

}
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			`/*`
			`* Copyright (c) 2024, MacDue <macdue@dueutil.tech>`
			`*`
			`* SPDX-License-Identifier: BSD-2-Clause`
			`*/`

			`#include <LibWeb/Painting/SVGMaskPaintable.h>`

			`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_DEFINE_ALLOCATOR(SVGMaskPaintable);`
LibWeb: Add calls to JS_{DECLARE,DEFINE}_ALLOCATOR() 2024-04-06 10:16:04 -07: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::Ref<SVGMaskPaintable> SVGMaskPaintable::create(Layout::SVGMaskBox const& layout_box)`
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			`{`
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<SVGMaskPaintable>(layout_box);`
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			`}`

			`SVGMaskPaintable::SVGMaskPaintable(Layout::SVGMaskBox const& layout_box)`
			`: SVGGraphicsPaintable(layout_box)`
			`{`
			`}`

			`}`