Linux: Performing graphics operations have no effect on the color data about fastbitmap

[Helmare]

I've ran more tests on the dev branch. I came to the conclusion that after a Graphics operation the Data and BaseBitmap are completely out of sync. All tests still pass on Windows.

[Igneom]

I've ran more tests on the dev branch. I came to the conclusion that after a Graphics operation the Data and BaseBitmap are completely out of sync. All tests still pass on Windows.

From what I noticed recently as well, the GDI+ implementantion on Linux is not close at all to how it works on Windows. I was having major memory leaks and issues with unmanaged memory, because I was using the Graphics.DrawImage to crop a regular Bitmap. On windows, everything worked normally and unmanaged memory on the GDI side was being released with no issues, as for on Linux, it was just piling up who knows where, and memory usage was as much as there was Ram and Swap available, as soon as I stopped using it, memory usage returned to normal.

It was just way faster to search on the whole Bitmap object for a pixel, using the FastBitmap implementation, than trying to crop the image using GDI first, and then passing it to the FastBitmap, in order to have a smaller search size.

What I think is happening, is that the changes that GDI+ library on Linux, makes on the bitmap, are all based on the default implementation of the Bitmap class, not taking into account that one can change the pointer to scan0 and change the type of the array on it, and maybe that's what is preventing it from updating the values properly, and also what's causing the memory leaks, since the pointer doesn't point to the object that it expects.

I think that a solution to that, would either be pointing these issues to the team that makes the GDI+ implementation on Linux, and hope that they understand that it's a real issue, and not an expected one since you're changing the scan0 pointer, therefore deviating from base implementation. Or keep the default implementation of the Bitmap object, and use the Data array as a sort of wrapper to the internal array, or some implementation similar to that, which I'm not entirely sure, but I think will decrease performance by a lot.

In my opinion, for now at least, just mention on the Readme that Graphics class manipulations are not compatible on Linux.

[Helmare]

I will change the readme to add a known issues section, and leave this issue open till it resolves. I have quite a bit of useful information as well since I've been working all day on this.

I've figured out there is a pointer discrepancy, but only when you start using the Graphics API. When you attempt to use the Graphics API, the BitmapData.Scan0 from the FastBitmap.BaseBitmap changes, so if you're not using FastBitmap the old pointer is lost. You can check this by comparing the FastBitmap.Scan0 (on the dev branch) to the BitmapData.Scan0 after a Graphics operation.

dotnet/runtime issue
It appears the memory leak triggered by getting a Graphics objects from an image. Ubuntu is affected by this, but not all Linux distros.

mono/libgdiplus
The native GDI+ library that .NET uses.

If I can force the outdated color data on FastBitmap to have the same pointer as the new one, it might be a temporary workaround. It won't stop the memory leak though unless I can trash the old data.

[Helmare]

I'm attempting to cause the issue in isolation from FastBitmap, but nothing seems to fail. I'll have more time to investigate soon.

The tests started failing after trying to manipulate the FastBitmap directly. The Graphics.FillRect affected both the Bitmap and FastBitmap, but after that they were out of sync. Scan0 remained the same for both through out the testing.