Performance profiling of the intervals track shows limits when dealing with truly enormous amounts of data. While a full reimplementation is unlikely, profiling traces reveal some small targeted enhancements we can explore as part of performance tuning planned in 0.13:
There is a forced reflow of the page mid render (perhaps revisit the order in which style values are read/set)
In combined track mode, each data element is represented by ~3 DOM elements (hit area, status node, and the actual colored rectangle). The hit areas are probably necessary, but we can explore explore eliminating or consolidating the status nodes to reduce DOM size. (esp in merged tracks node, where the status node is not larger than the data element)
A more ambitious alternative would be to explore mixed canvas-svg rendering: intervals are not layered, and elements are rectangles (two aspects in which hit areas are a concern). However, a mix of rendering styles would require code rewrites, potentially affect pan/zoom, and drastically affect "save as image" functionality; major internal changes would be required.
This would be a very large task: D3-> canvas is not magic. A clean implementation would be preferable to grafting canvas on.
Performance profiling of the intervals track shows limits when dealing with truly enormous amounts of data. While a full reimplementation is unlikely, profiling traces reveal some small targeted enhancements we can explore as part of performance tuning planned in 0.13:
A more ambitious alternative would be to explore mixed canvas-svg rendering: intervals are not layered, and elements are rectangles (two aspects in which hit areas are a concern). However, a mix of rendering styles would require code rewrites, potentially affect pan/zoom, and drastically affect "save as image" functionality; major internal changes would be required.
This would be a very large task: D3-> canvas is not magic. A clean implementation would be preferable to grafting canvas on.