<div><div>Hi,</div><div><br></div><div>>+    /*build a blue solid image to fill rectangle*/</div><div>></div><div>> Is this really necessary? Can't we use a solid brush?</div><div>Yes, if we use a solid brush, the GdipFillRectangleI will call GDI32_GdipFillPath,</div><div>then call brush_fill_path -> gdi32.FillPath , not call SOFTWARE_GdipFillRegion,</div><div>so GdipFillRectangleI will take effect.</div><div><br></div><div>>+    status = GdipFillRectangleI(graphics, (GpBrush*)brush, 0, 0,</div><div>>IMG_WIDTH*2, IMG_HEIGHT*2);</div><div>>+    expect(Ok, status);</div><div>></div><div>>This makes it unclear where the rectangle is located in the final</div><div>>image. We should leave part of the image unaffected by the fill, so we</div><div>>can check points outside of it.</div><div>My test aim is that expect GdipFillRectangleI filled the whole HDC image.</div><div>The HDC image is in a rectangle (4, 4)-(12, 12),</div><div>and the filled rectangle by GdipFillRectangleI is (0, 0)-(16, 16),</div><div>so the correct fill region should be (4,4)-(12,12), but the fill region</div><div>computed by the no patched code is (4,4)-(8,8).  </div><div><br></div><div>>I still think changing the region in alpha_blend_pixels_hrgn is wrong.</div><div>>Do I understand correctly that gdi32 does not apply the world</div><div>>transform (including the window origin) to the HREGION when we set it</div><div>>as a clipping region? If so, I think that the caller of</div><div>>alpha_blend_pixels_hrgn must apply the transform.</div><div>Yes, it is like that.</div><div>I wanted to modify ExtSelectClipRgn, but after I replace the native gdiplus.dll,</div><div>my test passed, so I think the SelectClipRgn is correct.</div><div><br></div><div>I wanted to apply the transform in SOFTWARE_GdipFillRegion before call</div><div>alpha_blend_pixels_hrgn, but this changes will affect these code in alpha_blend_pixels_hrgn:  </div><div><br></div><div>    if (graphics->image && graphics->image->type == ImageTypeBitmap)</div><div>    {</div><div>        ...</div><div>        </div><div>        hrgn = CreateRectRgn(dst_x, dst_y, dst_x + src_width, dst_y + src_height);</div><div>        </div><div>        ...</div><div>        </div><div>        stat = get_clip_hrgn(graphics, &visible_rgn);</div><div>        </div><div>        ...</div><div><br></div><div>        if (visible_rgn)</div><div>        {</div><div>            CombineRgn(hrgn, hrgn, visible_rgn, RGN_AND);</div><div>            DeleteObject(visible_rgn);</div><div>        }</div><div><br></div><div>        if (hregion)</div><div>            CombineRgn(hrgn, hrgn, hregion, RGN_AND);</div><div>        ...</div><div>    }</div></div><div><br></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> Thu, Dec 11, 2014 03:30 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 memory DCwhosewindoworigin point has changed</div></div><div> </div>-    if (graphics->hdc &&<br>-        (GetMapMode(graphics->hdc) != MM_TEXT ||<br>GetGraphicsMode(graphics->hdc) != GM_COMPATIBLE))<br>+    if (graphics->hdc)<br><br>I think this is a correct change.<br><br>+    /*build a blue solid image to fill rectangle*/<br><br>Is this really necessary? Can't we use a solid brush?<br><br>+    status = GdipFillRectangleI(graphics, (GpBrush*)brush, 0, 0,<br>IMG_WIDTH*2, IMG_HEIGHT*2);<br>+    expect(Ok, status);<br><br>This makes it unclear where the rectangle is located in the final<br>image. We should leave part of the image unaffected by the fill, so we<br>can check points outside of it.<br><br>I still think changing the region in alpha_blend_pixels_hrgn is wrong.<br>Do I understand correctly that gdi32 does not apply the world<br>transform (including the window origin) to the HREGION when we set it<br>as a clipping region? If so, I think that the caller of<br>alpha_blend_pixels_hrgn must apply the transform.<br><br>I think that SOFTWARE_GdipFillRegion will have to calculate two<br>regions: one in gdi32 logical coordinates to find the bounding box and<br>one in gdi32 device coordinates to pass to alpha_blend_pixels_hrgn.<br><br>Before we do this, we should also add a case to test_transformpoints,<br>in which we change the window origin of an HDC and then use it to<br>create a graphics object. I believe GdipTransformPoints will be<br>unaffected by the HDC, but if it is affected then we will need to take<br>a very different approach to solving this problem.<br><br>On Wed, Dec 10, 2014 at 12:33 AM, Changhui Liu<br><liuchanghui@linuxdeepin.com> wrote:<br>> Hi,<br>> After debug the get_graphics_bounds, I found that the default mapping mode<br>> and graphics<br>> mode of graphics->hdc are:<br>> MapMode=MM_TEXT, GraphicsMode=GM_COMPATIBLE.<br>><br>> If we don't use GetWindowOrgEx, then change this condition statement:<br>> if (graphics->hdc &&<br>>    (GetMapMode(graphics->hdc) != MM_TEXT || GetGraphicsMode(graphics->hdc)<br>> != GM_COMPATIBLE))<br>><br>> to<br>><br>> if (graphics->hdc )<br>><br>> is OK ?<br>><br>>>If I fill a<br>>>rectangle at (0,0) using GDI+, on an HDC with window origin (5,5),<br>>>what is the origin of that rectangle on the screen?<br>> I think the answer is (5,5).<br>><br>> Last, I modified my patch and test, please help me review it again when you<br>> are free.<br>> Thanks you.<br>><br>><br>><br>> ------------------ Original ------------------<br>> From:  "Vincent Povirk"<madewokherd@gmail.com>;<br>> Date:  Wed, Dec 10, 2014 01:51 AM<br>> To:  "wine-devel@winehq.org"<wine-devel@winehq.org>;<br>> Cc:  "刘昌辉"<liuchanghui@linuxdeepin.com>;<br>> Subject:  Re: gdiplus: fix GdipFillRectangleI no effect on memory DC<br>> whosewindoworigin point has changed<br>><br>> -        rect->X = 0;<br>> -        rect->Y = 0;<br>> +        /*The user maybe has called SetWindowOrgEx to change origin point*/<br>> +        POINT pt = {0, 0};<br>> +        GetWindowOrgEx(graphics->hdc, &pt);<br>> +        rect->X = pt.x;<br>> +        rect->Y = pt.y;<br>><br>> I don't think we should use GetWindowOrgEx in gdiplus. There are too<br>> many ways to change the mapping of co-ordinates for an HDC, and it<br>> doesn't make sense to specifically account for them all.<br>><br>> In get_graphics_bounds, we already have code that accounts for the HDC<br>> transform using DPtoLP. Maybe we should do that even when GetMapMode<br>> == MM_TEXT.<br>><br>> Transforming the region in alpha_blend_pixels_hrgn looks wrong to me,<br>> because we can't do that in the general case. Logical coordinates on<br>> the HDC may not be pixels.<br>><br>> Your test is very unclear. A good test for this should make it obvious<br>> how the HDC's transform affects GDI+ world coordinates. If I fill a<br>> rectangle at (0,0) using GDI+, on an HDC with window origin (5,5),<br>> what is the origin of that rectangle on the screen?<br></div><!--<![endif]--></includetail></div>