Re: filling area by color atack safety

Michael S <already5chosen@yahoo.com> writes:

On Tue, 19 Mar 2024 11:57:53 +0000
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>

On 19/03/2024 11:18, Michael S wrote:
>

On Mon, 18 Mar 2024 22:42:14 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
Here is the refinement that uses a resizing rather than
fixed-size buffer.

[...]

I did a little more investigation gradually modifying Tim's code
for improved performance without changing the basic principle of
the algorithm. [...]

I appreciate your doing this.  I developed independently a
couple of versions along similar lines.

So far, this algorithm is fastest among all "local" algorithms
that I tried.  By "local" I mean algorithms that don't try to
recolor more than one pixel at time.
>
"Non-local" algorithms i.e. yours and my recursive algorithm that
recolors St. George cross, are somewhat faster, [...].

I was confused by this statement at first but now I see that
"yours" refers to Malcolm's algorithm.

The nice thing about Tim's method is that we can expect that
performance depends on number of recolored pixels and almost
nothing else.

One aspect that I consider a significant plus is my code never
does poorly.  Certainly it isn't the fastest in all cases, but
it's never abysmally slow.

The second nice thing is that it is easy to understand.  Not as
easy as original recursive method, but easier than the rest of
them.
>
If you or somebody else is interested, here is [micro]optimized
variant:  [...]

Good show.  I will try to get my latest version posted soon.