Re: filling area by color atack safety

Michael S <already5chosen@yahoo.com> writes:

[...]

The most robust code that I found so far that performs well both
with small pictures and with large and huge, is a variation on the
same theme of explicit stack, may be, more properly called trace
back.  It operates on 2x2 squares instead of individual pixels.
>
The worst case auxiliary memory footprint of this variant is rather
big, up to picture_size/4 bytes.  The code is *not* simple, but
complexity appears to be necessary for robust performance with
various shapes and sizes.
>
[...]

I took a cursory look just now, after reading your other later
posting.  I think I have a general sense, especially in conjunction
with the explanatory comments.

I'm still hoping to find a method that is both fast and has
good memory use, which is to say O(N) for an NxN pixel field.

Something that would help is to have a library of test cases,
by which I mean patterns to be colored, so that a set of
methods could be tried, and timed, over all the patterns in
the library.  Do you have something like that?  So far all
my testing has been ad hoc.

Incidentally, it looks like your code assumes X varies more rapidly
than Y, so a "by row" order, whereas my code assumes Y varies more
rapidly than X, a "by column" order.  The difference doesn't matter
as long as the pixel field is square and the test cases either are
symmetric about the X == Y axis or duplicate a non-symmetric pattern
about the X == Y axis.  I would like to be able to run comparisons
between different methods and get usable results without having
to jump around because of different orientations.  I'm not sure
how to accommodate that.