Well for instance if you try to fill the entire screen from the top left hand corner, the algorithm will travel back and forth, down the entire screen until it gets to the bottom, at which point every single point on the screen will be in the stack.  Even though the screen is very simple, it poses the least efficient stack usage.

OK, thank.

I'm sure he is busy with KOS and such. The only algorithm I know is that recursive fill program that he used. To prevent that wonderful stack overflow, what you could do is essentially find the points that haven't been filled in, and go back and do the algorithm on those.  The only problem is how you would find which places still need to be filled in. I guess you could go through the stack, and delete (set to FF or something) the points that have pixels in the 4 directions (left, right, up, and down) and have their pixel filled in.  Then "collapse" the stack by going through and basically skipping over any FF data and moving the other points down.  So, if Data A is at location 1, B at location 2, and C at location 3. B is deleted, so when "collapsing", go through and copy C into B, and turn C into FF.

Basically, this clears the stack up. If it's really complicated, then not many of your points are going to get cleared, and it's going to loop forever because it can't delete anything on the stack, nor can it draw any more points. The main problem with this algorithm, though, are two-fold.

1) I haven't tested it completely. I made something like it, but I'm not sure if it was that part of the algorithm that worked.
2) Considering you are doing sub( a lot, you basically have to delete both the point and pointer off of the stack. It's quite complicated.

Not sure what else to do, though.