On Wed Mar 18 01:58:44 2026 +0000, Paul Gofman wrote:
Before that commit the color was de-facto initialized with black, that only changed that to white. color_bits which window_surface_get_color() gets are not from winex11.drv, they are from DIB section created with NtGdiCreateDIBSection() in window_surface_create(). NtGdiCreateDIBSection doesn't go to winex11, it allocates memory with NtAllocateVirtualMemory (and so that is initialized with 0 even before the 'white' commit). So it is yet unclear to me how any data in X image allocated in winex11 matter here. x11drv_surface_flush() should copy win32u data to the image. Is the win32u image maybe gets the garbled data before that (somehow blitted from x11 with XGetImage or else), or something goes wrong in x11drv_surface_flush itself so the data is not actually copied (to the required size) but X image is put to screen? `create_surface` in `winex11.drv/bitblt.c` calls `NtGdiDdDDICreateDCFromMemory`. This creates the GDI object that is stored in `color_bitmap` (and later fetched by `window_surface_get_color`). Is that what you mean?
Cherry-picking 18339eb0 fixes the issue (and as you say, produces a white screen instead of black). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10356#note_132588