Re: [PATCH v4 0/3] MR1003: gdiplus: Use atomic write for releasing GpImage lock.

[Zebediah Figura (＠zfigura)]

On Tue Oct 25 21:12:39 2022 +0000, Esme Povirk wrote:
> There are two different kinds of "locking" going on here. There's
> GdipLockBitmapBits, which isn't a locking mechanism at all but a way of
> accessing bitmap data, and the mutex we have protecting Bitmap objects.
> Also, error 7 is a gdiplus Status enum value named Win32Error, not a
> win32 error code, so this isn't ERROR_ARENA_TRASHED.
> This test case is entirely single-threaded, so it's not a race
> condition. The mutex-lock isn't really involved. It seems like gdiplus
> does not account for GdipImageRotateFlip being called while a bitmap is
> bits-locked. I would guess that RotateFlip changes the location of the
> image data, invalidating the state that UnlockBits needs to function
> correctly. What "should" happen in this situation is probably that
> GdipImageRotateFlip fails with WrongState, but it seems Windows doesn't
> do that.
> The patches here bring us closer to the (broken) Windows behavior,
> although I'm really not sure how Wine will end up handling this
> situation in practice.
> Ah, okay, I made a lot of assumptions, and didn't actually examine the test case. Sorry about that.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/1003#note_12127