Re: [fxtf-drafts] [geometry-2] Add DOMPolygon (#603)

After thinking about this some more, I think it would make more sense for open geometry to have its own interface like `DOMPath` as keeping polygons closed means that all the common utilities for things like intersections (see [comment](https://github.com/w3c/fxtf-drafts/issues/602#issuecomment-3041491334)).

For `DOMPolygon` we would of course have `DOMPolygon`, `DOMPolygonReadOnly` and `DOMPolygonInit`

- we likely would not validate or enforce geometry (no minimum vertices, winding order, self-intersection avoidance, etc) to match the other interfaces.
- polygons break from quads in that we can't have named `p1, p2, p3, p4` and instead would need to expose a `vertices()` or `points()` function.

One question here is around point representation. It is very common for polygons to be represented as flat point arrays internally for optimisation, but the existing geometry APIs work primarily with `DOMPoint` objects. I'm not sure we can have our cake and eat it too here, as exposing a flattened array breaks the existing API conventions, while using a flat array internally and exposing an object-based API could be just as expensive if not more as points would be constructed on demand. I'm very open to thoughts on this, because it would be great if DOMPolygon didn't rule out high-performance applications from the start.

-- 
GitHub Notification of comment by OrionReed
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/603#issuecomment-3041534752 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 6 July 2025 13:35:38 UTC