pixel mark

[mbostock]

This…

• Adds a pixel mark for generating raster images from xy-samples with fill (and optionally opacity).
• Adds the imageRendering property to the image mark (and pixel mark).
• Fixes an unfiled bug with boolean color scales that contain nullish values in the domain.
• Avoids computing the strokeWidth channel for marks that don’t support stroke.

I still need to write documentation, but I think this is functionally complete. I’m not 100% sure about the implementation, since adding and subtracting the default 0.5 can introduce tiny rounding errors (that go away when rounding during rendering, but still it would be nice to avoid them). I slightly wonder if it would be better to instead implement this as a canvas-based rect mark? Most other marks might want canvas-based rendering too… and in theory we Plot could even stack canvas and SVG elements rather than using svg:image (though that would break downloading).

Related #1122 #984.

[Fil]

We could probably learn a trick or two from @yurivish's unbelievably fast https://observablehq.com/@twitter/zoomable-density-scatterplot Writing the colors directly in the canvas data would probably be faster than using fillRect, since we don't need (nor want) anti-aliasing.

[Fil]

I often want a discrete quantitative scale, where I could draw a bar for a given unit, and it would have a width of 1 unit (minus insets).

For example, when drawing a bar chart for yearly data, I would prefer to write: x: {type:"linear", unit: 1} and use Plot.barY, than having to derive x1 and x2 with Plot.map and using Plot.rectY.

This option is slightly different from interval: 1, in that the bars would be ordinal-discrete, and centered on the unit, instead of covering [0, 1] we would cover [-0.5, 0.5]. And the scale would have a bandwidth. But (thinking out loud) maybe it is something we can do as an extension of interval: 1) an option to center things, and 2) add a bandwidth on the (continuous) scale.

[Fil]

I don't understand the i % m & 1 ? null : part?

[mbostock]

I wanted to test that both null and undefined produce the same output (transparent).

[Fil]

I think we also need to support mixBlendMode internally (with context.globalCompositeOperation), for when we have several pixels at the same location?

[mbostock]

Okay, I added mixBlendMode support, but it’s pretty much unusably slow presumably because it’s not hardware optimized.

I also added opacity support (as a fallback for fillOpacity, since both map to globalAlpha).

[Fil]

I've documented the pixel mark. Many of the common options do not work, but that's expected.

[mbostock]

Closing in favor of #1196.