Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: filling area by color atack safety
Date: Sat, 30 Mar 2024 00:54:19 -0700
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <86ttkoi28k.fsf@linuxsc.com>
References: <ut3669$21eur$1@i2pn2.org> <86h6h3nvyz.fsf@linuxsc.com> <865xxiok09.fsf@linuxsc.com> <20240319131842.00002138@yahoo.com> <utbuk3$qed7$1@dont-email.me> <20240319191859.00004bc8@yahoo.com> <86bk79m10l.fsf@linuxsc.com> <20240324202758.00001b75@yahoo.com> <86frwfjs0n.fsf@linuxsc.com> <20240325012844.0000685b@yahoo.com> <20240326185218.00005397@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sat, 30 Mar 2024 07:54:21 +0100 (CET)
Injection-Info: dont-email.me; posting-host="8552662d97416c03078d7b971fbb1163";
	logging-data="935362"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19lPNg0qqA6B4opmUbFG9hMyTNerd4ixwA="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:t/0vBRqNylnDd+BvyQS/zYnZy3Y=
	sha1:aKwzf2Iz/KuknFhc8qqFPoiU5nY=
Bytes: 2971

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.