Question: Windows FloodFill and WinBoard piece rendering

[hgm]

I have noticed for a long time that on my desktop PC, running Win2000, font-based rendering of WinBoard works well with most Chess fonts at almost any board size, while on my laptop (running Win XP), white pieces become (partly) transparent if you do not choose an extremely large board size. I used to suspect this had something to do with diplay resolution.

But now I finally got to figure out exactly how Allessando's code for this works, and where it goes wrong. It turns out it uses FloodFill for defining the 'outside' of a piece (which will be treated as transparent, to show the square on which the piece stands).

Now FloodFill, used to paint everything upto a given color (the color with which the piece symbol was printed) has the nasty property (on XP) that it 'spills' paint over the edges, and colors part of the defined boundary color as well. Sometimes so much that it actually obliterates the boundary lines completely, and the fill break into the inner piece regions (causing these to show up as transparent, eventually).

Now there is another mode of FloodFill (using the routine ExtFloodFill), which only replaces a given color (rather than overpainting all colors upto a given color). But this makes the opposite error: it leaves black spot outside the purple piece, when it tries to overpaint the outside region with white. This causes a white 'halo' to appear around the piece outlines, eventually.

Does anyone know about this problem? The FloodFill routines are described in the MicroSoft website, so I suppose they are part of Windows. (Called in the from of a DLL?) Or do other platforms (I compile under Cygwin) supply their own versions of these routines, and is it just a matter of getting an updated library for gcc?

[plattyaj]

I'm speculating a little but I suspect the floodfill is implemented by the graphics driver not by the library (or, to be more correct, that the library only implements it if it can't accelearate through hardware). So perhaps it's a driver problem, not an XP one?

Andy.

[hgm]

So what you are saying is that the call to FloodFill evetually invokes the driver, and it knows which driver to invoke because of the device context being the display? Could be, although it strikes me as strange that a Flood Fill would be a device-dependent operation.

Anyway, I was able to find a temporary work-around for WinBoard: after creating the piece mask by flood filling the outside in the reluctant mode (only overpainting the original outide color, leaving some of it unpainted, but never breaking through the piece outline) I overlay that with 4 shifted versions of itself. This shaves off the outer edge of the piece mask, and then I overprint it again with a black piece symbol to repair the outline where I shaved off to much.

When I shift two pixels in all 4 main direction, this seems to work reasonably well. But it is a hideous kludge, of course!

[wgarvin]

Why not just write your own flood fill routine that isn't buggy?

I'm assuming the piece masks are only created once at startup, or when you resize the board?

[hgm]

Yes, this would certainly be an alternative. But there is still so much to do on WinBoard, and to pogram my 7-men tablebase generator, and to make Joker SMP, and to write a Shogi program, that I really would like to avoid wasting much time on low-level programming like this.