gdiplus: fix GdipFillRectangleI no effect on memory DCwhosewindoworigin point has changed

[Vincent Povirk]

> 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.