Re: gdiplus: fix GdipFillRectangleI no effect on memory DC whosewindoworigin point has changed

[Changhui Liu]

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";
Date:  Wed, Dec 10, 2014 01:51 AM
To:  "[e-mail]"; 
Cc:  "刘昌辉"; 
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?