Hi Clemens,
thanks for getting at the bottom of this.
I think you have correctly identified the cause of the
problem.
Clemens Eisserer wrote:
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
In general, not necessarily - for an 8-bit visual a pixel is
an index into a Colormap.
replaced with xsdo->bgPixel != pixel)? pixel will never become 0
anyway?
It may - if the transparent pixel is 0th entry in the colormap.
I think we'll have to resort to another boolean which tells
whether bgPixel is valid - like you suggested.
I have tried to find the code review for this stuff but couldn't -
I seem to recall that there was an explanation offered why
the +1 trick should work, but I can't remember it. May be Jim can?
Thanks,
Dmitri
Looking foreward to hear your suggestions, lg Clemens
