Fixed painting on transparent layers

[Patrick Julien]

> I'm wondering -- whose code shall I nobble? ImageMagick is quite clear, and
> judging from the enum, Krita was based on its list of operations, but the
> Gimp's code supports more and more interesting operations, and the Gimp has
> optimisation code for lots of processors. At the moment I feel I'd better
> stick with ImageMagick.

ImageMagick doesn't use tiling, in fact, Krita originally was going to use 
ImageMagick  in whole.  However, some problems we're encountered an that plan 
was aborted.  You see, ImageMagick isn't really made for interactive use, 
it's easy to lock up the GUI if your doing something too big and tool kit 
doesn't offer that many callbacks.

More so, one annoying problem is that the magick is thread safe but not 
re-entrant.   That means if you check for events from one of magicks 
callback, and the user starts something that goes back into Image Magick, the 
application will lock up since it's the same thread trying to re-acquire the 
same mutex.

In any case, I digress in my madness here, the code for doing the composite 
operations should actually be quite straightforward.  The only thing is that 
results for such things can be cached (like in the Gimp) for they only do 8 
bits color per channel.  In magick, they don't since they can configure 
magick by default to be 64 bits per color channel (or maybe it's 32, it don't 
matter really, it's a lot).   So, since Krita can be configured like magick 
to do any number of bits per color channel, it maybe safer to follow magicks 
code.