I don't think switching to doubles will help. The extra precision should get our result closer to 6.0, but 5.999999 will still fail.
We should look for a more direct way to calculate src_pointf, to avoid introducing rounding errors. Maybe if we start by subtracting ptf[0] from dst_point, we can more directly transform that to coordinates relative to the source rectangle, then add srcx,srcy. This needs more thought than I can put in right now, but I suspect the current solution is more complicated than it needs to be.
On Sun, Nov 23, 2014 at 9:23 PM, Liu Changhui liuchanghui@linuxdeepin.com wrote:
Dear Vincent: The PixelFormat32bppRGB shuld be PixelFormat32bppARGB in the test_GdipDrawImagePointsRectNeedResample function of my patch.
In test_GdipDrawImagePointsRectNeedResample, the first src_pointf valuse is : X=5.992676, src_pointf.Y=0.000000 when the destination pixel is(x=699,y=0), and srcx=6.000000,srcy=0.000000,srcwidth=48.000000,srcheight=26.000000,
so the follow if statement will test false : if (src_pointf.X >= srcx && src_pointf.X < srcx + srcwidth && src_pointf.Y
= srcy && src_pointf.Y < srcy+srcheight)
then the destination pixel (x=699,y=0) will be filled with zero value, but we expect that pixel shoule be filled a color same as the source image.
I think make these variables: dst_to_src_points, src_pointf, x_dx, x_dy, y_dx, y_dy all use 64bit double float type maybe can fixed this situation. But GpointF and GpMatrix has used 32bit float type, and many gdiplus functions depended on them.
Can you give me some advice ? Thank you!
------------------ Original ------------------ From: "Vincent Povirk"madewokherd@gmail.com; Date: Sun, Nov 23, 2014 12:57 PM To: "刘昌辉"liuchanghui@linuxdeepin.com; Cc: "Sebastian Lackner"sebastian@fds-team.de; "wine-devel"wine-devel@winehq.org; Subject: Re: gdiplus:GdipDrawImagePointsRect has a nosie vertical lineoutputafter resampled
This will cause us to draw outside of the destination when the image is both enlarged and rotated.
That if statement is there to make sure we only draw to the area inside the shape defined by the points array. src_pointf should be within the range defined by srcx/srcy/srcwidth/srcheight if and only if (x,y) is within that shape. If that's not the case, it probably means we're calculating src_pointf incorrectly for the whole image, not just the edges.
I'm not sure Sebastian realized this, but in this case GdipBitmapGetPixel is different from reading the image directly. Because PixelFormat32bppRGB does not store alpha data in the bitmap, GdipBitmapGetPixel will always return an alpha value of 255, and you will get a non-zero value even if the pixel is black. I suggest testing for the exact value you expect. That should also remove the need for the trace() calls.