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 ------------------
Date:  Wed, Dec 10, 2014 01:51 AM
To:  "wine-devel@winehq.org"<wine-devel@winehq.org>;
Cc:  "刘昌辉"<liuchanghui@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?