Support canvas.getContext("2d", {alpha: boolean, pixelFormat: string}) #935
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an amped-up version of most of #678. ("Most" because it doesn't add the
flush
function or allow passing a buffer as that PR adds. "Amped-up" because all of the APIs work AFAICT, with the caveats noted in the docs.) My priority was to support indexed PNG encoding, but a lot of stuff came with it. I'm happy to split the 1st/2nd commits from the 3rd and 4th. Indexed PNG encoding is maybe out of scope and is something that could be extracted into a separate C++ addon, but the first two support the standard.Docs for the major addition: https://github.com/zbjornson/node-canvas/tree/formats#image-pixel-formats-experimental
Adds support for the standard
alpha
attribute:canvas.getContext("2d", {alpha: false})
. In the browser tests, node-canvas matches Firefox as well as ever, and Chrome seems to have a few bugs in which canvases randomly do get an alpha channel.Adds support for the proposed
pixelFormat
attribute:canvas.getContext("2d", {pixelFormat: <format>})
. The color space proposal is still fairly early, and in particular the format names look like they'll change (see the open issues), but adding aliases for other formats for backwards compatibility in the future will be trivial. Even if that proposal doesn't move forward, this is nice functionality to have and a clean API (i.e. it adds options to the standardcontextOptions
object instead of positional args to the Canvas constructor).RGBA32
,RGB24
andA8
have full support:getImageData
/putImageData
/createImageData
all work.RGB16_565
also has full support, but note: TheImageData.data
property is aUint16Array
instead of aUint8ClampedArray
because it doesn't make sense as a uint8. This follows the linked proposal AFAICT --ImageData
has multiple storage types there, but it's not specified how bit widths like 5-6-5 map to integral types. This commit is easy to drop if there's any disagreement.A1
andRGB30
have partial support:getImageData
/putImageData
/createImageData
don't work because I wasn't sure how the data should be represented. Cairo packs pixels together but also has a padded stride (e.g. an A1 canvas with width 10 has a stride of 4 bytes). We could either pack all pixels together or keep them padded. This is a ton of bit manipulation given that these APIs can work on regions of a canvas. 😓Adds support (non-standard) for indexed PNG encoding. 🎉 See the two new files in
examples/
. That particular image fits losslessly into 474 bytes when indexed (left), vs 1.92 kB when RGBA32 (right).Note that it's sorta hard to specify an exact palette index using the 0-1 value in
rgba()
syntax. Adding#rgba
and#rrggbbaa
support will allow integers to be provided.Right now only
pngStream
supports this, but if this PR lands, thentoBuffer
and maybetoDataURL
should support it also. For the former, I'd propose moving all of thetoBuffer
options into an object since the current API is awkward (see Move PNG_* constants to constructor, clean up toBuffer API #934).No breaking API changes.
Fixes #332