Runtime: Graphics.Transform does not affect clip region specified by Path on Linux

[RusKnyaz]

The clip region remains in the same place, regardless of the transformation matrix. The issue is not reproducible on Windows, but reproducible on Linux. The issue is not reproducible with using of graphics.SetClip(Rectangle).

1. Run the following code on Linux:
   ```c#
   var bmp = new Bitmap(200, 50);
   using (var graphics = Graphics.FromImage(bmp))
   using(var pen = new Pen(Color.Black, 1f))
   {
   graphics.Clear(Color.White);

   graphics.TranslateTransform(50f,0f);
   
   var clipRectangle = new Rectangle(0, 0, 50, 50);
   graphics.DrawRectangle(pen, clipRectangle); //mark the clip area
   
   // set clip area using path
   var path = new GraphicsPath();
   path.AddRectangle(clipRectangle);
   graphics.SetClip(path);
   
   // Draw diagonal line to be clipped by rectangle
   graphics.DrawLine(pen, -50,0,150,50);
   

   }

   bmp.Save("/mnt/c/Temp/clip_linux.png", ImageFormat.Png);
   ```

2. Compare results of running the code on windows and linux

Observed: Clip area does not affected by transformation matrix and located at 0,0 point.

Expected: Clip area should affected by translation matrix and shifted to the right by 50 pixels like on Windows.

[danmosemsft]

@qmfrederik presumably these Unix specific issues are most likely bugs in libgdiplus and would need fixes there.

[qmfrederik]

@danmosemsft Yes, that's correct. @hughbe has done quite some work in the libgdiplus area the past months, they are at the PR stage now.

@akoeplinger what's the current plan for moving PRs forward in libgdiplus?

[RusKnyaz]

Where shall I post new issues: to dotnet/corefx or to https://github.com/mono/libgdiplus?

[danmosemsft]

@RusKnyaz I defer to @qmfrederik but in general if it reproes in Unix but not Windows it would likely be best to file it directly against libgdiplus. I expect they will want to confirm you're using the latest libgdiplus, although it sounds like in this case there are some changes that aren't submitted yet.

[safern]

Same as other issues, most likely libgdiplus since they don't reproduce in Windows, so moving to future.

[qmfrederik]

@RusKnyaz A lot of fixes were recently committed for libgdiplus.

Just to be sure, can you try with the latest version of libgdiplus?
You should be able to do:

git clone https://github.com/mono/libgdiplus
cd libgdiplus
./autogen.sh
make
sudo make install

to patch libgdiplus on your system. Make sure to remove the version of libgdiplus that ships with your Linux distro, though.

If you're on Ubuntu 16.04 and up to it, you can use packages from my ppa - https://launchpad.net/~quamotion/+archive/ubuntu/ppa.

[safern]

@qmfrederik thanks for the update, I can test it as well. The repro seems very clear.

[safern]

@qmfrederik I built libgdiplus locally, installed it and linked it to /usr/lib/libgdiplus.so and I got the same incorrect output, so seems this wasn't fixed in libgdiplus yet :(

[akoeplinger]

@filipnavara might be another challenge for you? :)

[filipnavara]

Not really being an expert on the code, here are my observations.

The API for setting clip rectangle applies a matrix transformation to the rectangle:

GpStatus WINGDIPAPI
GdipSetClipRect (GpGraphics *graphics, REAL x, REAL y, REAL width, REAL height, CombineMode combineMode)
{
    ...
    /* if the matrix is empty, avoid region transformation */
    if (!gdip_is_matrix_empty (graphics->clip_matrix)) {
        cairo_matrix_t inverted;

        gdip_cairo_matrix_copy (&inverted, graphics->clip_matrix);
        cairo_matrix_invert (&inverted);

        GdipTransformRegion (region, &inverted);
    }

and so does the GdipSetClipRegion API, but GdipSetClipPath doesn't do it.

Knowing this, the workaround would be to call graphics.SetClip(new Region(path), CombineMode.Replace);. If you can confirm that it helps then I can try to patch GdipSetClipPath to do the right thing.

[safern]

Knowing this, the workaround would be to call graphics.SetClip(new Region(path), CombineMode.Replace);. If you can confirm that it helps then I can try to patch GdipSetClipPath to do the right thing.

I just confirmed this, and you are correct, calling graphics.SetClip(new Region(path), CombineMode.Replace) which will Pinvoke into GdipSetClipRegion works fine and produces:

which is the expected output.