-
Notifications
You must be signed in to change notification settings - Fork 555
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
[QUESTION] Is SKPixMap.GetPixelSpan supposed to be readonly? #1240
Comments
Technically yes... It uses the "readonly" version. But that pointer is also returned for the writeable. So there is actually no real difference. I think it is good to add both the writeable version and the generic. |
A "workaround" right now is to just create your own span: var span = new Span<T> ((void*)pixmap.GetPixels (), pixmap.BytesSize); That is almost exactly what I do under the hood. In fact, that is what this feature will be. |
Thanks, did that, and also added the unmanaged constraint. I just discovered that .net core 3 now has native SIMD intristics... C# is now exciting even for low level hackers ;-) |
Thanks for the tip on the unmanaged constraint! |
Just be aware that skia flips the bits depending on the CPU endian-ness. |
Fixes #1240 Also "cache" the info object in size so we don' have to hop the interop.
Let me know what you think of #1242 |
* Expose a generic, writable span for the pixels * Fixes #1240 * "Cache" the info object in size so we don' have to hop the interop. * Raw pixels depend on the CPU endianness
SKPixMap.GetPixelSpan
returns aReadOnlySpan<byte>
, not aSpan<byte>
So one can't use that for direct pixel manipulation.
Is this by design? I believe a pix-map is writable no?
Skia itself also has
void* SKPixMap::writable_addr()
.It would also be useful to have a generic version, to avoid having to call
MemoryMarshal
methodsThe text was updated successfully, but these errors were encountered: