Having a separate implementation for Canvas is problematic in the longterm.

[pixelzoom]

For #47 and phetsims/fourier-making-waves#165, @jonathanolson pointed out that having a separate implementation for Canvas (CanvasChartNode, CanvasLinePlot) is problematic in the longterm. For example, as we get more support for WebGL to improve performance, code that uses the Canvas-based classes will be stuck with Canvas performance. An API like Node that chooses its rendered (or allows you to specify a renderer) would be preferrable.

I'm not sure how we get there from here.

[pixelzoom]

Unassigning because I doubt that we'll see progress on this for awhile. Let me know when you'd like to discuss.

[samreid]

This doesn't seem like something we need to solve right away. All of the canvas charts already have a non-canvas implementation, which could be rendered in SVG or WebGL if scenery one day supports that. Yes, the canvas implementation is a holdover, but who knows if/when we will have more WebGL support in scenery? Also, if we have WebGL support in scenery, perhaps we will build or use an adapter that lets us efficiently reuse a lot of our canvas code, like https://github.com/jagenjo/Canvas2DtoWebGL?

Yes, it's unfortunate that bamboo's canvas and scenery renderers have different APIs, but it doesn't seem practical to unify those APIs eagerly. But if others argue this is important and should be done soon, perhaps elevate this to epic-level issue? Thoughts @jonathanolson and @pixelzoom?

[pixelzoom]

I see @jonathanolson's point about this. If the renderer hadn't been abstracted out eagerly in scenery, there's little chance that we would have been able to do it later, especially if Node (and its subclasses) had different APIs for different renderers. So if we think it's valuable to do that for bamboo, it should probably be done eagerly.

[samreid]

It seems we should add this to our subgroup meeting alongside #45