Fixed painting on transparent layers

Leonard Rosenthol leonardr at
Sun Jan 25 15:46:30 CET 2004

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 

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

Leonard Rosenthol                            <mailto:leonardr at>

More information about the kimageshop mailing list