Ah, right, I remember now. Cool.

My thinking was that you're looping the WORST on things that never get set to black. In other words, your algorithm uses up more CPU the less text there is in the foreground layer. One word by itself on the screen uses up more CPU than a dense paragraph of text.

Since the text is usually fewer pixels than the bacground, my thinking was that it'd make more sense to do it the other way round, not doing an inner loop until you hit some lit text in the foreground layer.

There's gotta be a way where you scan through the pixels looking for the lit text in the foreground layer, and only THEN do your little circle around that pixel looking for transparent pixels and marking the black spots onto the background layer where the foreground is NOT lit. The trick is coming up with a simple system whereby you can short-circuit that inner loop the most efficiently so that you're not re-blacking stuff that's already been blacked. Looking at the problem from that angle, I keep telling myself there's gotta be a way to do that efficiently and shortcut a lot of the brute force work.

Or, perhaps there's a totally lateral-thinking way of getting the same effect without having to iterate through every single pixel. That'd be the real win, and there's so many examples of this kind of thing in other fields (edge-finding algorithms in paint programs, chroma-key applications in digital video), that there's gotta be some prior art which shows how to do it. There's just gotta be. I have no idea where, but hopefully someone else here on the board would know.