Graphics.Collage: Not possible to make shapes with holes.

[justinmanley]

The standard wisdom on making shapes with holes in them using HTML canvas seems to be to draw the outer shape in one direction, then to draw the inner shape in the other direction. Once both shapes have been drawn, then they are filled as a unit. This results in a hole in the form of the inner shape.

The current Graphics.Collage library doesn't allow for shapes to be drawn separately, then filled together.

Perhaps the addition of a function groupShapes : List Shape -> Shape would be sufficient?

[justinmanley]

Thinking further...

The HTML canvas API isn't necessarily the best API for drawing shapes. What if Elm programmers could express these ways of combining shapes in a declarative fashion that was easy to read and understand, rather than being buried in the clockwise/counterclockwise direction in which the coordinates describing a shape happen to be listed?

For example, Graphics.Canvas might expose the following additional functions:

intersect, union, symmetricDifference : Shape -> Shape -> Shape

Symmetric difference would allow for the expedient creation of shapes containing holes.

This would be much more difficult to implement than the groupShapes function I described in my first comment. I'm not sure how these high-level functions could map on to the nonzero winding rule that is built in to canvas elements.

I haven't come across any precedents for these kinds of functions. Popular JavaScript graphics libraries for canvas - e.g. fabric.js and paper.js don't put shapes together in this way; neither does Haskell's Diagrams library.

That said, I think that the functions described above would provide an elegant set of primitives worthy of Elm.

[justinmanley]

Thinking further...

The HTML canvas API isn't necessarily the best API for drawing shapes. What if Elm programmers could express these ways of combining shapes in a declarative fashion that was easy to read and understand, rather than being buried in the clockwise/counterclockwise direction in which the coordinates describing a shape happen to be listed?

For example, Graphics.Canvas might expose the following additional functions:

intersect, union, symmetricDifference : Shape -> Shape -> Shape

Symmetric difference would allow for the expedient creation of shapes containing holes.

This would be much more difficult to implement than the groupShapes function I described in my first comment. I'm not sure how these high-level functions could map on to the nonzero winding rule that is built in to canvas elements.

I haven't come across any precedents for these kinds of functions. Popular JavaScript graphics libraries for canvas - e.g. fabric.js and paper.js don't put shapes together in this way; neither does Haskell's Diagrams library.

That said, I think that the functions described above would provide an elegant set of primitives worthy of Elm.

[justinmanley]

There are unambiguous ways to intersect, union, and take the symmetric difference of closed shapes which are not self-intersecting using the nonzero winding rule.

There is, however, some ambiguity regarding closed self-intersecting shapes (which might be created using Graphics.Collage.polygon). In particular, it's not immediately clear how to determine the orientation (clockwise/counterclockwise) for a shape which is self-intersecting.

[justinmanley]

There are unambiguous ways to intersect, union, and take the symmetric difference of closed shapes which are not self-intersecting using the nonzero winding rule.

There is, however, some ambiguity regarding closed self-intersecting shapes (which might be created using Graphics.Collage.polygon). In particular, it's not immediately clear how to determine the orientation (clockwise/counterclockwise) for a shape which is self-intersecting.

[evancz]

Sorry this did not get attention til now! The Graphics.* modules now live in evancz/elm-graphics so I am trying to get stuff migrated over there.

That said, I would like to keep that API stable for now. I expect to be focusing on <canvas> for professional users and "friendly graphics" for learning as separate use cases. Progress will be made when those start happening.

[evancz]

Sorry this did not get attention til now! The Graphics.* modules now live in evancz/elm-graphics so I am trying to get stuff migrated over there.

That said, I would like to keep that API stable for now. I expect to be focusing on <canvas> for professional users and "friendly graphics" for learning as separate use cases. Progress will be made when those start happening.