Hi, After debug the get_graphics_bounds, I found that the default mapping mode and graphics mode of graphics->hdc are: MapMode=MM_TEXT, GraphicsMode=GM_COMPATIBLE. If we don't use GetWindowOrgEx, then change this condition statement: if (graphics->hdc && (GetMapMode(graphics->hdc) != MM_TEXT || GetGraphicsMode(graphics->hdc) != GM_COMPATIBLE)) to if (graphics->hdc ) is OK ?
If I fill a rectangle at (0,0) using GDI+, on an HDC with window origin (5,5), what is the origin of that rectangle on the screen? I think the answer is (5,5).
Last, I modified my patch and test, please help me review it again when you are free. Thanks you. ------------------ Original ------------------ From: "Vincent Povirk"<madewokherd(a)gmail.com>; Date: Wed, Dec 10, 2014 01:51 AM To: "wine-devel(a)winehq.org"<wine-devel(a)winehq.org>; Cc: "刘昌辉"<liuchanghui(a)linuxdeepin.com>; Subject: Re: gdiplus: fix GdipFillRectangleI no effect on memory DC whosewindoworigin point has changed - rect->X = 0; - rect->Y = 0; + /*The user maybe has called SetWindowOrgEx to change origin point*/ + POINT pt = {0, 0}; + GetWindowOrgEx(graphics->hdc, &pt); + rect->X = pt.x; + rect->Y = pt.y; I don't think we should use GetWindowOrgEx in gdiplus. There are too many ways to change the mapping of co-ordinates for an HDC, and it doesn't make sense to specifically account for them all. In get_graphics_bounds, we already have code that accounts for the HDC transform using DPtoLP. Maybe we should do that even when GetMapMode == MM_TEXT. Transforming the region in alpha_blend_pixels_hrgn looks wrong to me, because we can't do that in the general case. Logical coordinates on the HDC may not be pixels. Your test is very unclear. A good test for this should make it obvious how the HDC's transform affects GDI+ world coordinates. If I fill a rectangle at (0,0) using GDI+, on an HDC with window origin (5,5), what is the origin of that rectangle on the screen?