Yes, if we use a solid brush, the GdipFillRectangleI will call GDI32_GdipFillPath, then call brush_fill_path -> gdi32.FillPath , not call SOFTWARE_GdipFillRegion, so GdipFillRectangleI will take effect.
Ah, you're right, sorry.
My test aim is that expect GdipFillRectangleI filled the whole HDC image. The HDC image is in a rectangle (4, 4)-(12, 12), and the filled rectangle by GdipFillRectangleI is (0, 0)-(16, 16), so the correct fill region should be (4,4)-(12,12), but the fill region computed by the no patched code is (4,4)-(8,8).
I would prefer that the image be made larger and some points outside the fill region be tested.
I wanted to modify ExtSelectClipRgn, but after I replace the native gdiplus.dll, my test passed, so I think the SelectClipRgn is correct.
Native gdiplus probably works differently. As a rule, we do not check what API calls native makes when implementing our version, to make sure we ours is an independent implementation and not affected by Microsoft's copyright.
But Wine's gdi32 is more mature and well-tested than gdiplus, so ExtSelectClipRgn probably works correctly.
I wanted to apply the transform in SOFTWARE_GdipFillRegion before call alpha_blend_pixels_hrgn, but this changes will affect these code in alpha_blend_pixels_hrgn:
I see, this is a larger problem than it first appeared because we must account for this behavior every time we set a clipping region.
I believe we should modify SOFTWARE_GdipFillRegion, alpha_blend_pixels_hrgn's call to CreateRectRgn, and get_clip_hrgn separately.
The other functions using get_clip_hrgn will have a similar problem (if a clipping region is set on the Graphics object), and changing it will fix them as well.
For get_clip_hrgn and SOFTWARE_GdipFillRegion, I would create a new function that takes a GpGraphics* and GpRegion* in gdiplus device coordinates, and returns an HRGN in gdi32 device coodrinates. For now, this would just call GdipGetRegionHRgn followed by OffsetRgn where necessary, but it gives us the ability to do something more complicated if we need to in the future.
I don't think we should check GetMapMode(). That was my mistake when I started to account for transforms in get_graphics_bounds.
The necessary changes to get_graphics_bounds, SOFTWARE_GdipFillRegion, get_clip_hrgn, and alpha_blend_pixels_hrgn should be split into separate patches, and you can follow them with your test.