Eto.Bitmap.Lock problem with macOS Big Sur

[TomQv]

Hi Curtis,

I'm not sure if this is already fixed, since I'm on a quiet old level of your sources.
With new macOS Big Sur the following bitmap.Lock returns null for pixels:

Eto.Drawing.Bitmap bitmap = somebitmap();
using (var pixels = bitmap.Lock())
{
}

Any ideas?

[cwensley]

Hm, I'm not seeing the issue on the latest code. What is somebitmap()? Are you loading an existing image or creating a new Bitmap object?

I am noticing that the BitmapData.BytesPerPixel is reporting '8' for some images on Big Sur, probably due to supporting HDR so that will probably need fixing.

[TomQv]

I did some more investigation. As said, I'm for some reason on an old version of Eto.
Testing with the current version of Eto this is fixed, the problem was in BitmapHandler.EnsureRep().
So bitmap.lock is working.

But now there is another problem, because bitmap.lock() returns a 64-bit bitmap. This is coming from BitmapHandler.EnsureRep().
So yes, maybe related to some new HD features on Retina display?

[TomQv]

Ok, it seems that the problem is in BitmapHandler.EnsureRep()
rep as NSBitmapImageRep always gives null and then bmprep = new NSBitmapImageRep(new CGRect(CGPoint.Empty, Control.Size)); returns a 64bit bitmap.
I found the following workaround. just calling bmprep = new NSBitmapImageRep(rep.CGImage); instead. This returns the rep in the same pixelmode like the original. Don't know, if its the right way, but it seems to work for me.

[TomQv]

Again, all this only with Big Sur, testing on a iMac retina 5K 27inch late 2015.

[TomQv]

Thanks for the fix, but still one small bug in BitmapHandler.cs, line 352, should be:
bmprep = new NSBitmapImageRep(IntPtr.Zero, size.Width, size.Height, bitsPerComponent, numComponents, rep.HasAlpha, false, rep.ColorSpaceName, bytesPerRow, bitsPerPixel);

[cwensley]

@TomQv thanks for the feedback! I've added that fix in.