Different result with drawImageAt on windows and macos

Hi Jules,

Running the following code:

[code]Image img1(Image::ARGB, 1, 1, true);
Image img2(Image::ARGB, 1, 1, true);
img1.setPixelAt(0, 0, Colour(0xff808080));
img2.setPixelAt(0, 0, Colour(0xff000000));
Graphics g(img2);
g.setColour(Colour(0x80ff0000));
g.drawImageAt(&img1, 0, 0, true);

cerr << "original pixel: " << img1.getPixelAt(0, 0).toString() << “\n”;
cerr << "final pixel: " << img2.getPixelAt(0, 0).toString() << “\n”;
[/code]

produces the final pixel 0xff7f0000 on windows, and 0xff3f0000 on mac. (I’m using svn version latest rev 551). Is it a bug or is there something I’m missing ?

They should be identical… The only difference I can think of is that the pc version might use some SSE optimisations, but even that shouldn’t make a difference. Very odd. How did you come across the problem?

I took the time to track the bug, it is in juce_LowLevelGraphicsSoftwareRenderer.cpp / blendAlphaMapARGB

It was an endianness problem, the result was correct on mac/ppc and windows/i386 , but not on mac/i386

The line unsigned
unsigned int srcAlpha = src;
should be replaced by something like
unsigned int srcAlpha = ((PixelARGB
)src)->getAlpha();

ooops that fix was completely wrong… It is the LowLevelGraphicsSoftwareRenderer::clippedFillAlphaChannelWithColour that needs to be fixed, not blendAlphaMapARGB

Just replace the #if JUCE_MAC test by #if JUCE_BIG_ENDIAN and everything works fine

Oh, excellent - thanks for tracking it down! There’s also a similar line in clippedFillAlphaChannelWithImage() that needs changing. I guess those two lines fell through the net when I was porting to the intel mac!