OLEAUT32: transparency fix for OLEPicture
Alex Villacis Lasso
a_villacis at palosanto.com
Thu Apr 21 14:22:03 CDT 2005
Alex Villacis Lasso wrote:
> > The bad news is that this fix uncovers an even greater bug: builtin
> oleaut32 is unable to create a valid AND mask
> > for a bitmap with transparency. The end result is that the AND mask
> (which is now created in the first place)
> > holds a garbage bitmap, rather than a valid outline of the sample
> image.
>
> Well, I figured out why the AND mask was garbage - the bitblt
> operation was using the width and height from the bitmap structure
> used to create the DIB bitmap, without considering that the height had
> a negative sign (to account that a Windows DIB fills scans in the
> reverse order from a GIF). Therefore the AND mask was copied to an
> area completely outside of the target area for the temp HDC, so the
> target area remained unchanged (and therefore undefined).
>
> Then I had this problem that, once the image was being rendered as
> transparent, the transparent areas showed my desktop below the sample
> window. This indicated that the transparent bitmap was not being
> announced as transparent by OLEPicture. This was a trivial fix in
> get_Attributes(), so that now the window background was rendered
> before the bitmap was blasted.
>
> Third, the transparency was (incorrectly) selecting as transparent
> some areas that were not meant as transparent in the original GIF. The
> root cause was that the algorithm used to build the AND mask was
> relying on a RGB value extracted from the transparency index, which is
> incorrect - there is no guarantee that the RGB value pointed to by the
> transparency index is not being used by any other opaque palette
> index. So the AND mask building was rewritten to use the transparency
> index directly.
Apparently this patch has *not* been applied, despite what the Changelog
says. So here it goes again, this time updated for 20050419
Changelog:
* Fix leftover negative sign in height parameter for transparent bitmap
* Properly announce whether bitmap is transparent in get_Attributes
* GIF transparency is now palette-index based, instead of RGB based
* Keep original bitmap and XOR mask separate, so that get_Handle returns
original bitmap
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wine-oleaut32-olepicture-transparency_fix_resend.patch
Type: text/x-patch
Size: 4883 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20050421/99d9b2dd/wine-oleaut32-olepicture-transparency_fix_resend.bin
More information about the wine-patches
mailing list