-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux: Performing graphics operations have no effect on the color data #4
Comments
I've ran more tests on the dev branch. I came to the conclusion that after a Graphics operation the |
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. |
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 dotnet/runtime issue mono/libgdiplus If I can force the outdated color data on |
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. |
The code below results in no change to
FastBitmap.Data
when it is ran on Linux (Ubuntu 20.04).The text was updated successfully, but these errors were encountered: