Fixed painting on transparent layers

[Leonard Rosenthol]

At 8:26 AM -0500 1/25/04, Patrick Julien wrote:
>ImageMagick doesn't use tiling,

	Very true.


>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,

	Boy, there's an understatement ;).

	IM is definitely NOT made for interactive work - it always 
focused on quality and research over performance and stability.  This 
was one of the reasons that we forked off GraphicsMagick - to focus 
on (what to us) were more important, performance and stability.


>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.

	True, but that's probably the case with most toolkits.  They 
do NOT expect to be re-entered in the way you describe.  Your 
software would be better served (for a number of reasons) using 
multiple threads - one for UI/UE and then forking off for imaging 
operations...


>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).

	IM is 16bit per channel/component by default.  GM is 8.

	But either can be compiled time set to up to 64bpc.


LDR
-- 
---------------------------------------------------------------------------
Leonard Rosenthol                            <mailto:leonardr at lazerware.com>
                      			     <http://www.lazerware.com>