[Bug 42740] New: Icons with transparency no longer rendering correctly
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(a)winehq.org Reporter: wine(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42740 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTOURBUG --- Comment #1 from Alexandre Julliard <julliard(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42740 --- Comment #2 from Johannes <wine(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42740 --- Comment #3 from Alexandre Julliard <julliard(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42740 --- Comment #4 from Johannes <wine(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42740 --- Comment #5 from Alexandre Julliard <julliard(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42740 --- Comment #6 from Johannes <wine(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42740 --- Comment #7 from Johannes <wine(a)sagagames.de> --- Created attachment 57781 --> https://bugs.winehq.org/attachment.cgi?id=57781 Wine 2.4 vs Windows 7 icons -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42740 --- Comment #8 from Alexandre Julliard <julliard(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42740 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Austin English <austinenglish(a)gmail.com> --- Closing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42740 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED --- Comment #10 from Austin English <austinenglish(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org