[Proposal]: Add standard geometric evaluation methods (Intersects, GetBounds, StrokeContains) to PathGeometry

[wenlino]

Problem statement

The class currently lacks several fundamental geometric evaluation methods. While it provides basic rendering and path definition capabilities, developers frequently need to perform spatial queries (such as collision detection, bounding box calculation, and stroke hit-testing) that are not natively supported. System.Windows.Media.PathGeometry
Currently, developers are forced to write custom extension methods or rely on third-party libraries to implement these standard geometric judgments, leading to duplicated logic across the ecosystem.

Why the current approach is insufficient

Missing Intersection Checks: There is no native method to determine if two instances overlap or cross each other. Developers must manually flatten paths and perform complex segment-segment intersection math.PathGeometry
No Native Bounding Box: does not expose a direct method. Calculating the bounding rectangle requires iterating through all figures and segments manually, which is inefficient and error-prone (especially for Bezier curves).PathGeometryGetBounds()
Stroke Hit-Testing is Unavailable: While exists for checking if a point is inside the filled area, there is no equivalent method to check if a point lies on the outline/stroke of the path.FillContains(Point)StrokeContains(Point, tolerance)
Ambiguous Containment: There is no native way to check if one geometry completely encloses another ().Encloses(PathGeometry)

Type of change

Behavior change

Expected impact

High: This will significantly reduce boilerplate code for UI developers working with custom geometries, hit-testing, drag-and-drop interactions, and collision detection. It will bring closer to feature parity with other modern 2D graphics APIs.PathGeometry
All WPF / .NET UI Developers: Anyone working with custom vector graphics, hit-testing, or interactive UI elements will benefit from these native methods.
Performance: Native implementations can be highly optimized at the framework level (e.g., using internal C++/Direct2D bounds calculations), offering better performance than managed C# extension methods.

Alternatives or tradeoffs

Custom Extension Methods: Developers can continue to write their own extensions (as I have done in my own projects). However, this leads to fragmented solutions, potential bugs in custom math implementations, and suboptimal performance compared to native framework support.
Third-party Libraries: Relying on external libraries for basic geometric math adds unnecessary dependencies to projects. These are fundamental geometric operations that belong in the core framework.

Additional context

To make a complete geometric primitive, I propose adding the following methods:PathGeometry

public class PathGeometry : Geometry
{
    // 1. Calculate the bounding rectangle
    public Rect GetBounds();

    // 2. Check if a point is on the outline/stroke
    public bool StrokeContains(Point point, double tolerance = 1.0);

    // 3. Check if this geometry overlaps with another
    public bool Intersects(Geometry geometry);

    // 4. Check if this geometry fully encloses another
    public bool Encloses(Geometry geometry);
}

Before submitting

• I searched for existing issues and discussions first.
• I described why this belongs in MewUI core rather than only in app-level code.

[al6uiz]

Thank you for the proposal.

MewUI's current geometry implementation is centered around PathGeometry. The proposed functionality is not limited to adding a few individual methods. It requires a broader geometry operation model covering bounds calculation, flattening, fill and stroke hit-testing, geometry relationship evaluation, widening, and outlining.

As an initial step, the following API surface for PathGeometry will be treated as a long-term target.

public Rect GetBounds();

public PathGeometry GetFlattenedPathGeometry();
public PathGeometry GetFlattenedPathGeometry(
    double tolerance,
    ToleranceType type);

public bool FillContains(Point hitPoint);
public bool FillContains(
    Point hitPoint,
    double tolerance,
    ToleranceType type);

public double GetArea();
public double GetArea(
    double tolerance,
    ToleranceType type);

public bool FillContains(PathGeometry geometry);
public bool FillContains(
    PathGeometry geometry,
    double tolerance,
    ToleranceType type);

public IntersectionDetail FillContainsWithDetail(
    PathGeometry geometry);

public IntersectionDetail FillContainsWithDetail(
    PathGeometry geometry,
    double tolerance,
    ToleranceType type);

public bool Intersects(PathGeometry geometry);
public bool Encloses(PathGeometry geometry);

public Rect GetRenderBounds(Pen pen);
public Rect GetRenderBounds(
    Pen pen,
    double tolerance,
    ToleranceType type);

public bool StrokeContains(Pen pen, Point hitPoint);
public bool StrokeContains(
    Pen pen,
    Point hitPoint,
    double tolerance,
    ToleranceType type);

public IntersectionDetail StrokeContainsWithDetail(
    Pen pen,
    PathGeometry geometry);

public IntersectionDetail StrokeContainsWithDetail(
    Pen pen,
    PathGeometry geometry,
    double tolerance,
    ToleranceType type);

public PathGeometry GetWidenedPathGeometry(Pen pen);
public PathGeometry GetWidenedPathGeometry(
    Pen pen,
    double tolerance,
    ToleranceType type);

public PathGeometry GetOutlinedPathGeometry();
public PathGeometry GetOutlinedPathGeometry(
    double tolerance,
    ToleranceType type);

The exact signatures and behavioral contracts may be refined during implementation.

The eventual goal is to introduce a common Geometry abstraction and expand the model with geometry types such as LineGeometry, RectangleGeometry, EllipseGeometry, and GeometryGroup. At that stage, operations currently accepting PathGeometry can be generalized to accept Geometry.