http://bugs.winehq.org/show_bug.cgi?id=33084
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru 2013-03-02 23:03:53 CST --- (In reply to comment #3)
Created attachment 43773 [details] possible fix
The attached patch seems to fix it, but I don't really understand why. It seems to me that a fully transparent pixel is a fully transparent pixel, and it shouldn't matter what's in the RGB channels. Nor does the application seem to do anything weird to draw it.
And I can't think of an easy way to generate a test image for this.
It shouldn't be too hard to create a sample PNG image with PLTE and tRNS chunks, and then check the palette returned by WIC for this image.
Dmitry, you sent a gdiplus change earlier that preserved the RGB channels when converting from ARGB -> RGB. Any thoughts on this?
That patch simply avoided sending PARGB to StretchBlt since only GdiAlphaBlend understands PARGB as input, and StretchBlt just ignores alpha from ARGB passed to it (if you mean that memcpy() patch).