algorithm comparison
not really an issue, but I wanted to dump a reference here too:
I made a small comparison between some boolean operation algorithms and wanted to share the results: https://daef.github.io/poly-bool-comparison/

Great thing! can you please explain the metrics? I didn't understand the abbrevations
I'd like to forward you to the graphicsmagick documentation but it's not very helpful.
Thanks a lot!
Really really good tool. Thank you.
have you found a new use case for this hack @Llorx ? i thought it doesn't do much on its own so there's no real benefit to make it more reusable.
@daef Just to see the problems some libraries have with certain polygons. The red/green error deviation thingy was really useful. I was looking for a library with good rectangle handling.
i guess when there are 'just' axis aligned rects one could do much better than with a generic polygon lib, is performance your main concern or are you looking for something correct/robust? :)
EDIT: reopened, i accidentaly closed the issue
Both, correctness and performant. I need to merge about 200 hundred rectangles into a single polygon in less than 16ms (for drawing to a canvas at 60 fps) but I also need for it to be drawn correctly. I thought that this new algorithm will help, but nope. I lose a lot of frames, so forgot about this solution and now I'm looking for webgl.
Was it too slow or incorrect?
Seems like rasterizing is a more convenient approach in your case.
Yeah, maybe I could draw to a canvas and extract the result image as a mask. That's the next step if webgl gets too complicated haha.
In this case it was slow and incorrect, but the slowness I think is because I'm asking too much, and worse if looking for a JavaScript script instead of native code. About the correctness, I was getting some weird edges. This is the black mask image where you can see all the rectangles/squares, some of them overlap:

When the algo was passed with union, I was getting something like this (drawn with paint, but you get the point):

By the way, I noticed that is impossible for a normal computer in the browser to have a decent union performance with that amount of rectangles, so I forgot about it.
Yes, with "cascading" approach it's very heavy. I have faced that problem before in https://github.com/w8r/ploygon-offset
But if you are dealing with rectangles and they are axis-aligned as I see on the picture, it only makes sense to go for raster approach.