https://bugs.winehq.org/show_bug.cgi?id=56800
--- Comment #7 from Esme Povirk madewokherd@gmail.com --- Huh, OK, so the largest image in that screenshot is 923 pixels wide. We can see a "seam" going diagonally from the top-right corner.
The image is loaded from a bitmap resource: GdipCreateBitmapFromResource -> GdipCreateBitmapFromHBITMAP -> GdipCreateBitmapFromScan0. GdipCreateBitmapFromScan0 was modified in this patch: We now allocate memory instead of an HBITMAP to store the data. The bitmap is 24-bit.
There's a bit of an implicit assumption embedded in GdipCreateBitmapFromHBITMAP, which is that the stride of the newly-created bitmap object will match the stride of the HBITMAP. If there were a mismatch, it could cause something like what we're seeing.
GdipCreateBitmapFromScan0 rounds up to the nearest DWORD boundary, which according to https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapi... is the same calculation that HBITMAPs use. However, 923 * 3 bytes = 2769, which rounded to the nearest DWORD boundary is 2772, the same stride that would be used for a 924-pixel wide bitmap. If gdi32 were actually using a stride of 2769, that would explain what we're seeing. It would also mean that before this change, any attempt to access those bitmap objects without going through gdi32 would've been broken (but they probably used to be drawn with gdi32 and thus fine).