home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!univ-lyon1.fr!ghost.dsi.unimi.it!rpi!usc!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!exodus.Eng.Sun.COM!speedsail.Eng.Sun.COM!srnelson
- From: srnelson@speedsail.Eng.Sun.COM (Scott R. Nelson)
- Newsgroups: comp.graphics
- Subject: Re: "fill" algorithm
- Date: 27 Jan 1993 16:39:26 GMT
- Organization: Sun Microsystems Inc., Mountain View, CA
- Lines: 31
- Message-ID: <lmdeluINNs7o@exodus.Eng.Sun.COM>
- References: <kenb.0pwj@amiganet.chi.il.us> <1993Jan27.122027.9461@ulrik.uio.no>
- NNTP-Posting-Host: speedsail
-
- eivind@kih.no (eivind hagen) writes:
-
- >Ken Boi (kenb@amiganet.chi.il.us) wrote:
- >> Could someone inform me as to how a 'fill' works in graphical painting.
- >
- >If you want it EASY, make a recursive call to the 4 adjacent pixels, and
- >for each pixel, check if it is the right color, and then change the
- >pixels color.
- >This is very slow, needs a BIG stack, but is foolproof!
-
- I tried that once and even with 100 megabytes of virtual memory it
- ran out of stack space after filling less than 500,000 pixels on the
- background of a complex scene. The system also went through a major
- thrashing period before the program died. That doesn't fit my
- definition of "foolproof".
-
- A very simple change would be to pick a pixel, then fill horizontally
- in both directions as far as possible. Once done, go check all of the
- pixels above and below that filled region. This uses much less stack
- space and is also faster. There are certainly more speed optimizations
- that could be made to avoid redundant tests if you like to experiment.
-
- You might also want to consider checking the 8 adjacent pixels rather
- than 4, if you want it to go through diagonal holes.
-
- ---
-
- Scott R. Nelson srnelson@eng.sun.com
- Sun Microsystems
-
- "Proofread carefully to see if you any words out."
-