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
On Tue Oct 25 21:03:54 2022 +0000, Zebediah Figura wrote:
> That behaviour sounds an awful lot like gdiplus isn't thread-safe after
> all. E.g. error 7 is ERROR_ARENA_TRASHED. Should this code really have a
> lock at all?
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1003#note_12125
On Sun Oct 23 20:06:50 2022 +0000, Esme Povirk wrote:
> I think that behavior is strange enough that we shouldn't worry about
> it, at least not until we see a real app doing this. Thank you for checking.
That behaviour sounds an awful lot like gdiplus isn't thread-safe after all. E.g. error 7 is ERROR_ARENA_TRASHED. Should this code really have a lock at all?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1003#note_12119
This is wine-7.0.1-rc1, so not ready yet to merge.
--
v5: Release 7.0.1.
gitlab: Import the gitlab CI from the master branch (devel tree)
winetest: Don't require an email if we have a URL.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/955
When we are clipping (due to fullscreen), certain operations are bugged (such as creating another window on top, grabbing the window during a size-move operation, changing mouse capture, etc) so we must temporarily unclip first.
Seems unclipping it temporarily during such operation is enough to fix this.
This probably wasn't very obvious in practice because most times "fullscreen" means a single non-resizeable window with no menus and so on (e.g. fullscreen games), but that's not always the case.
--
v2: winex11.drv: Correctly handle clipping for fullscreen windows.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1153