[PATCH 0/1] MR6782: gdi32: Add support of monochrome bitmap to get_bitmap_info()

[AlexeyLushnikov (＠AlexeyLushnikov)]

Emfdc.c. Function get_bitmap_info.
Added filling of bmiColors for monochrome bitmaps when get_bitmap_info creates a new bitmap.

[PATCH 1/1] gdi32: Add support of monochrome bitmap to get_bitmap_info()

[AlexeyLushnikov]

From: AlexeyLushnikov

---
 dlls/gdi32/emfdc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/dlls/gdi32/emfdc.c b/dlls/gdi32/emfdc.c
index e48da848a96..d936a0e718b 100644
--- a/dlls/gdi32/emfdc.c
+++ b/dlls/gdi32/emfdc.c
@@ -201,6 +201,10 @@ static UINT get_bitmap_info( HDC *hdc, HBITMAP *bitmap, BITMAPINFO *info )
             ((DWORD *)dib_info->bmiColors)[1] = 0x00ff00;
             ((DWORD *)dib_info->bmiColors)[2] = 0x0000ff;
             break;
+        case 1:
+            ((DWORD *)dib_info->bmiColors)[0] = 0x000000;
+            ((DWORD *)dib_info->bmiColors)[1] = 0xffffff;
+            break;    
         default:
             if (dib_info->bmiHeader.biBitCount > 8) break;
             if (!(palette = GetCurrentObject( *hdc, OBJ_PAL ))) return FALSE;

[Jinoh Kang (＠iamahuman)]

Jinoh Kang (@iamahuman) commented about dlls/gdi32/emfdc.c:
>          ((DWORD *)dib_info->bmiColors)[1] = 0x00ff00;
>          ((DWORD *)dib_info->bmiColors)[2] = 0x0000ff;
>          break;
> -
>    case 1:
> -
>        ((DWORD *)dib_info->bmiColors)[0] = 0x000000;
> -
>        ((DWORD *)dib_info->bmiColors)[1] = 0xffffff;

Monochrome bitmaps are not always black and white when blitted to a colored DC. Have you checked if the colors should be in fact {GetTextColor(), GetBgColor()}? Should we respect their palettes just like in the default case, if they have any? Wouldn't this cause regression in that case?

[AlexeyLushnikov (＠AlexeyLushnikov)]

On Sat Nov 16 12:02:41 2024 +0000, Jinoh Kang wrote:
> Monochrome bitmaps are not always black and white when blitted to a
> colored DC. Have you checked if the colors should be in fact
> {GetTextColor(), GetBgColor()}? Should we respect their palettes just
> like in the default case, if they have any? Wouldn't this cause
> regression in that case?

Yes, you are right. Setting colors to black and white isn't correct.

In my case monochrome bitmap is a mask for removing background on other bitmap.
Probably, I need to set the palette before making a bitblt for the mask.
Then the default case should work as you said.

But what confuses me is that in Windows the palette setting is not required.
And also, when rendering in Wine (not in the EMF context), bitblt works as expected without palette setting.

Unfortunately, I can't determine the reasons for this now.
I should to figure out how bitblt works in non-EMF contexts

[Jinoh Kang (＠iamahuman)]

> But what confuses me is that in Windows the palette setting is not required. And also, when rendering in Wine (not in the EMF context), bitblt works as expected without palette setting.

A monochrome device-dependent bitmap does not (necessarily) have a palette. It's the conversion to another color format (e.g., RGB) that the palette or fg/bg colors become necessary.