Dear all, I have modified the patch and add more test functions, thank you for your advice.
Because I found that graphics->hdc and graphics->hwnd are both nil when this condition statement: if (graphics->image && graphics->image->type == ImageTypeBitmap) is true in alpha_blend_pixels_hrgn function, So I think there's no chance to change the window origin point for graphics who created from a bitmap image .
So I not modify alpha_blend_pixels_hrgn, I think the changes in get_clip_hrgn and SOFTWARE_GdipFillRegion will not affect alpha_blend_pixels_hrgn. My thought was wrong about alpha_blend_pixels_hrgn in last mail.
Please help me review it again when you are free. Thanks a lot.
------------------ Regards.
------------------ Original ------------------ From: "Vincent Povirk"madewokherd@gmail.com; Date: Fri, Dec 12, 2014 01:39 AM To: "Changhui Liu"liuchanghui@linuxdeepin.com; Cc: "wine-devel@winehq.org"wine-devel@winehq.org; Subject: Re: gdiplus: fix GdipFillRectangleI no effect on memoryDCwhosewindoworigin point has changed
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.