Support Canvas.

[mbostock]

Should hexbin.hexagon implement the symbol type interface? But it has a specific radius, not an arbitrary size…

Should the hexagon method take a context? But then you have to construct a path buffer manually?

Should the hexbin take a context? And then render like a shape? (Rendering either a mesh of individual hexbins?) Maybe?

[ghost]

Sorry for the delay in replying to this pull request.

Here's what I think so far (subject to major revisions):

• Should hexbin.hexagon implement the symbol type interface? -- I don't think so since I can't imagine a situation where it would be useful in an ordinal scale like all the other symbols (if there is such a use case, let me know). As you mentioned above, converting from a size to radius might require some arithmetic that could get tricky.
• Should the hexagon method take a context? -- I'm not sure exactly what this question means, could you please clarify?
• Should the hexbin take a context? And then render like a shape? -- I feel the answers to these are yes and yes in order to maintain maximum compatibility with d3-shape as well as allow rendering to either SVG or Canvas web interfaces.

Would love to hear your thoughts. Also, I may be wrong on any/all of this, so please feel free to correct any errors.

[syntagmatic]

A v3 version of d3-hexbin that takes a Canvas context here: http://bl.ocks.org/syntagmatic/002ef2fb5c1dc2df5821

My opinion is d3-hexbin shouldn't deal directly with Canvas or SVG path strings. It should output arrays of coordinates. Turning that array into a path string or a Canvas subroutine should be a convenience method or a separate utility like d3-path.

But practically since the plugin already supported SVG, adding a convenient way to render to Canvas instead would be nice. In this case, the API should be similar to d3.geoPath. A method to access the raw coordinates would still be useful.