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
Provide better pixel operations for Canvas #866
Comments
Looks like CanvasPixelArray -> Uint8ClampedArray in the underlying DOM, which provides more flexible access as well: http://www.khronos.org/registry/typedarray/specs/latest/#7.1 |
Added Triaged label. |
There is no way to distinguish an array for an NxM image from a MxN image or any other shape with N*M/4 pixels. ImageData has the needed missing info - the width, but that would incur the overhead of an extra indirection which would make bound checking optimization harder due to potential aliasing and heap mutation. It might be reasonable to work in pixel indexes: pixels.setRGBA(x + y*width, r, g, b, a); void setRGBA(int pixelIndex, int r, int g, int b, int a) { The asymmetry between writing whole pixels at pixel positions and reading channels from channel positions is displeasing. |
Added this to the Later milestone. |
Removed the owner. |
Added html-api label. |
Removed html-api label. |
Removed Area-HTML label. |
Removed this from the Later milestone. |
Removed Oldschool-Milestone-Later label. |
(From iposva):
Consider better APIs to write canvas pixels than a CanvasPixelArray.
E.g., setRGBA(x, y, r, g, b, a) instead of CanvasPixelArray's byte accesses.
i = y*n+x;
pixel[i] = r;
pixel[i+1] = g;
pixel[i+2] = b;
pixel[i+3] = a;
becomes:
pixels.setRGBA(x, y, r, g, b, a)
The text was updated successfully, but these errors were encountered: