Skip to content
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

Closed
ziriax opened this issue Apr 18, 2020 · 6 comments · Fixed by #1242
Closed

[QUESTION] Is SKPixMap.GetPixelSpan supposed to be readonly? #1240

ziriax opened this issue Apr 18, 2020 · 6 comments · Fixed by #1242
Milestone

Comments

@ziriax
Copy link
Contributor

ziriax commented Apr 18, 2020

SKPixMap.GetPixelSpan returns a ReadOnlySpan<byte>, not a Span<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 methods

@mattleibow
Copy link
Contributor

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.

@mattleibow
Copy link
Contributor

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.

@ziriax
Copy link
Contributor Author

ziriax commented Apr 19, 2020

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 ;-)

@mattleibow
Copy link
Contributor

Thanks for the tip on the unmanaged constraint!

@mattleibow
Copy link
Contributor

Just be aware that skia flips the bits depending on the CPU endian-ness.

mattleibow added a commit that referenced this issue Apr 19, 2020
Fixes #1240
Also "cache" the info object in size so we don' have to hop the interop.
@mattleibow
Copy link
Contributor

Let me know what you think of #1242

mattleibow added a commit that referenced this issue Apr 23, 2020
* 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
@mattleibow mattleibow added this to the v1.68.2 milestone Apr 29, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Aug 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants