Hacker News new | past | comments | ask | show | jobs | submit login

This works well for the problem space - does it work well for a drawing app where the canvas is always changing?



Modifying it to work with a changing canvas shouldn't be too difficult.

You could simply clear the mask of a bounding box around the changes, and recalculate the masks inside that bounding box. In addition to hitting the "edge" of a drawing area, the algorithm can now also bit the edge of the bounding box and encounter an outside mask - which means the inside mask and outside mask can be ORed to get a new composite mask.

You'd have to take care with the fact that an edit can join two previously-separate areas together, but that'd also be a simple OR. The more tricky scenario is an edit splitting an existing area in two. It is reasonably easy to determine that an edit is trying to split an area, but it is not immediately obvious to me how you'd efficiently determine that no connection between two halves exists outside the edit bounding box: how do you distinguish a "|" turning into a ":" from an "O" turning into a "C"?


It can be made work. Precompute the image when the flood fill tool is activated and it’s fine, since you only have to do it once


Tbh adding a background pixel only needs to check its four surrounding to see if it joined seperate areas, adding a fourground is harder I expect you need Dijkstra.


Interesting – what behavior would you want there? Statically filled area, or a shifting area depending on the other pixels?


For an app like this I would expect it to be static. Basically the same behavior MS Paint has had for decades.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: