<div><div>Dear all,</div><div>I have modified the patch and add more test functions, thank you for your advice.</div><div><br></div><div>Because I found that graphics->hdc and graphics->hwnd are both nil when this condition statement: </div><div>    if (graphics->image && graphics->image->type == ImageTypeBitmap)</div><div>is true in alpha_blend_pixels_hrgn function,    </div><div>So I think there's no chance to change the window origin point for graphics who created from a bitmap image<span style="line-height: 1.5;"> .  </span></div><div><span style="line-height: 1.5;"><br></span></div><div>So I not modify alpha_blend_pixels_hrgn, I think the changes in get_clip_hrgn and</div><div>SOFTWARE_GdipFillRegion will not affect alpha_blend_pixels_hrgn.  </div><div>My thought was wrong about alpha_blend_pixels_hrgn in last mail.</div><div><br></div><div>Please help me review it again when you are free. </div><div>Thanks a lot.</div><div> </div></div><div><br></div><div><br></div><div><sign signid="0"><div style="color:#909090;font-family:Arial Narrow;font-size:12px"><br><br><br><br>------------------</div><div style="font-size:14px;font-family:Verdana;color:#000;"><div>Regards.</div>
</div></sign></div><div> </div><div><includetail><div> </div><div> </div><div style="font:Verdana normal 14px;color:#000;"><div style="FONT-SIZE: 12px;FONT-FAMILY: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="FONT-SIZE: 12px;background:#efefef;padding:8px;"><div id="menu_sender"><b>From: </b> "Vincent Povirk"<madewokherd@gmail.com>;</div><div><b>Date: </b> Fri, Dec 12, 2014 01:39 AM</div><div><b>To: </b> "Changhui Liu"<liuchanghui@linuxdeepin.com>; <wbr></div><div><b>Cc: </b> "wine-devel@winehq.org"<wine-devel@winehq.org>; <wbr></div><div><b>Subject: </b> Re: gdiplus: fix GdipFillRectangleI no effect on memoryDCwhosewindoworigin point has changed</div></div><div> </div>> Yes, if we use a solid brush, the GdipFillRectangleI will call<br>> GDI32_GdipFillPath,<br>> then call brush_fill_path -> gdi32.FillPath , not call<br>> SOFTWARE_GdipFillRegion,<br>> so GdipFillRectangleI will take effect.<br><br>Ah, you're right, sorry.<br><br>> My test aim is that expect GdipFillRectangleI filled the whole HDC image.<br>> The HDC image is in a rectangle (4, 4)-(12, 12),<br>> and the filled rectangle by GdipFillRectangleI is (0, 0)-(16, 16),<br>> so the correct fill region should be (4,4)-(12,12), but the fill region<br>> computed by the no patched code is (4,4)-(8,8).<br><br>I would prefer that the image be made larger and some points outside<br>the fill region be tested.<br><br>> I wanted to modify ExtSelectClipRgn, but after I replace the native<br>> gdiplus.dll,<br>> my test passed, so I think the SelectClipRgn is correct.<br><br>Native gdiplus probably works differently. As a rule, we do not check<br>what API calls native makes when implementing our version, to make<br>sure we ours is an independent implementation and not affected by<br>Microsoft's copyright.<br><br>But Wine's gdi32 is more mature and well-tested than gdiplus, so<br>ExtSelectClipRgn probably works correctly.<br><br>> I wanted to apply the transform in SOFTWARE_GdipFillRegion before call<br>> alpha_blend_pixels_hrgn, but this changes will affect these code in<br>> alpha_blend_pixels_hrgn:<br><br>I see, this is a larger problem than it first appeared because we must<br>account for this behavior every time we set a clipping region.<br><br>I believe we should modify SOFTWARE_GdipFillRegion,<br>alpha_blend_pixels_hrgn's call to CreateRectRgn, and get_clip_hrgn<br>separately.<br><br>The other functions using get_clip_hrgn will have a similar problem<br>(if a clipping region is set on the Graphics object), and changing it<br>will fix them as well.<br><br>For get_clip_hrgn and SOFTWARE_GdipFillRegion, I would create a new<br>function that takes a GpGraphics* and GpRegion* in gdiplus device<br>coordinates, and returns an HRGN in gdi32 device coodrinates. For now,<br>this would just call GdipGetRegionHRgn followed by OffsetRgn where<br>necessary, but it gives us the ability to do something more<br>complicated if we need to in the future.<br><br>I don't think we should check GetMapMode(). That was my mistake when I<br>started to account for transforms in get_graphics_bounds.<br><br>The necessary changes to get_graphics_bounds, SOFTWARE_GdipFillRegion,<br>get_clip_hrgn, and alpha_blend_pixels_hrgn should be split into<br>separate patches, and you can follow them with your test.<br></div><!--<![endif]--></includetail></div>