Hello again, Seems I've identified the bug: _X11SDOps.bgPixel is used as a hint wether the background was already filled with the bgColor specified in drawImage or not - if (xsdo->bgPixel != pixel + 1) it thinks that the transparent pixels of the image have already been painted to the bgColor which works except in the case when pixel = -1, bgColor is always initialized with 0 so for this case the transparent pixels get never ever their color.
I now have a few ideas how this could be changed: 1.) Add a jboolean-field to the _X11SDOps struct, indicating wether the bgColor is valid or not. Currently bgColor=0 servers this purpose. It seems to be in my eyes the best approach, however I don't know wether this could break any API/ABI? 2.) Choose a value for the case bgColor==invalid which cannot be taken by a pixel+1 value. As far as I guess the pixel+1 should serve this purpose - never let the pixel become 0 ... but it seems wrong-way thought. Is pixel always a negative value? If yes couldn't the check be replaced with xsdo->bgPixel != pixel)? pixel will never become 0 anyway? Looking foreward to hear your suggestions, lg Clemens
