https://bugs.winehq.org/show_bug.cgi?id=42740
Bug ID: 42740 Summary: Icons with transparency no longer rendering correctly Product: Wine Version: 2.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: wine@sagagames.de Distribution: ---
Using Wine 2.4 on Xubuntu 16.10, icons in OpenMPT (https://openmpt.org/) no longer have a transparent background. They all render with a white background and even some bogus pixels, indicating that the 8-bit alpha is ignored completely.
They were rendered correctly on Wine 2.0 the last time I checked.
https://bugs.winehq.org/show_bug.cgi?id=42740
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #1 from Alexandre Julliard julliard@winehq.org --- This is because Wine used to handle the alpha channel incorrectly, and OpenMPT has a workaround for it. Now that Wine is fixed (by 89d31e42fc64bf78d9390c55baa4fc8ec54539e2) the workaround does the wrong thing.
You can disable the workaround by running OpenMPT with the /noWine flag. I'd suggest filing a bug with OpenMPT asking them to remove the workaround, or to only enable it for Wine < 2.4.
https://bugs.winehq.org/show_bug.cgi?id=42740
--- Comment #2 from Johannes wine@sagagames.de --- I am actually the OpenMPT developer who implemented this work-around.
The work-around we utilize for Wine is also used on other systems which do not support 32-bit images with alpha channel, e.g. when using a 24-bit graphics mode. What Wine 2.4 does is neither consistent with Windows in 32-bit mode, nor with Windows in 16-bit or 24-bit mode. In the latter case (which is applied for Wine), the 8-bit alpha is pre-calculated and reduced to a 1-bit mask and the image is loaded with ILC_COLOR24 | ILC_MASK. However, Wine now ignores this 1-bit mask completely, which it previously did not.
https://bugs.winehq.org/show_bug.cgi?id=42740
--- Comment #3 from Alexandre Julliard julliard@winehq.org --- (In reply to Johannes from comment #2)
I am actually the OpenMPT developer who implemented this work-around.
Great!
The work-around we utilize for Wine is also used on other systems which do not support 32-bit images with alpha channel, e.g. when using a 24-bit graphics mode. What Wine 2.4 does is neither consistent with Windows in 32-bit mode, nor with Windows in 16-bit or 24-bit mode. In the latter case (which is applied for Wine), the 8-bit alpha is pre-calculated and reduced to a 1-bit mask and the image is loaded with ILC_COLOR24 | ILC_MASK. However, Wine now ignores this 1-bit mask completely, which it previously did not.
It seems to me that the issue is that you pass a mask with an alpha channel, so if we are in 32-bit mode, the alpha channel breaks the reduction to 1-bit (previously it worked because alpha was ignored in 32->1 blits, but this was incorrect). My suspicion is that you'd get the same behavior if you used the 24-bit code path on a modern 32-bit Windows, but I haven't verified it.
It's very possible that there are still other issues with the imagelist code, but it hasn't changed lately so I'd expect the issues to be identical in 2.0.
https://bugs.winehq.org/show_bug.cgi?id=42740
--- Comment #4 from Johannes wine@sagagames.de --- I adjusted the Wine-specific check to be applied to old Wine versions only.
Reading the documentation, it does indeed seem like we really should use a 1-bit bitmap for the mask. Doing so makes the icons show up correctly as well. However, even modern Windows does not seem to be too strict about this API contract and just accepts any bit depth for the alpha mask.
Just to be clear what OpenMPT does / did: For creating the 1-bit mask, it sets the alpha channel of all pixels in the mask to 255, and depending on whether the pixel corresponding to the mask entry should be drawn or not, it sets the remaining three bytes to 255 or 0.
Windows just ignores the alpha channel (or expects it to be 255), only taking the actual pixel value (zero/non-zero) into account. But Wine seems to ignore the entire mask no matter if the alpha channel is set to 0 or 255 for any of the mask pixels. I think Wine needs to use the mask no matter which bit depth it has, and probably also ignore the alpha channel of the mask.
https://bugs.winehq.org/show_bug.cgi?id=42740
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- (In reply to Johannes from comment #4)
I adjusted the Wine-specific check to be applied to old Wine versions only.
Thanks!
Windows just ignores the alpha channel (or expects it to be 255), only taking the actual pixel value (zero/non-zero) into account. But Wine seems to ignore the entire mask no matter if the alpha channel is set to 0 or 255 for any of the mask pixels. I think Wine needs to use the mask no matter which bit depth it has, and probably also ignore the alpha channel of the mask.
We are using BitBlt to copy the mask to 1-bpp. The way it works is that pixel values are matched against the background color, which is 00ffffff by default, so an alpha of 255 is never going to match, and the mask will be all ones. If you set alpha to 0 always, it should work as expected.
I believe Windows behaves the same way. I've hacked OpenMPT to make it always take the Wine code path, and I see the white background on Windows too.
If you have a case where the behavior is different without an explicit Wine check, I'd be interested to try it.
https://bugs.winehq.org/show_bug.cgi?id=42740
--- Comment #6 from Johannes wine@sagagames.de --- My apologies, there is indeed a white background on regular Windows as well. I'm not sure what I did different the last time I tested it.
However, there is still a difference (see attached screenshot) that might be somewhat relevant. The upper part of the screenshot is Wine 2.4, the lower part Windows 7. I think Wine applies transparency to a few pixels there (see the last two icons), while Windows doesn't.
https://bugs.winehq.org/show_bug.cgi?id=42740
--- Comment #7 from Johannes wine@sagagames.de --- Created attachment 57781 --> https://bugs.winehq.org/attachment.cgi?id=57781 Wine 2.4 vs Windows 7 icons
https://bugs.winehq.org/show_bug.cgi?id=42740
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- The extra pixel at the bottom right of the icon is definitely strange. I've verified that it's already present in the data we get in ImageList_Add, so there must be something else going on.
https://bugs.winehq.org/show_bug.cgi?id=42740
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=42740
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #10 from Austin English austinenglish@gmail.com --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.
-
wine-bugs＠winehq.org