HeatMap is currently rendered using rect glyphs. This approach is flexible, since it allows the heatmap to be overlaid on arbitrary categorical axes, and each rectangle is drawn independently of the axis ordering. However, for large heatmaps with many categories, it becomes extremely inefficient: each rectangle (pixel) must be sent and rendered individually, which both increases data transfer and slows down rendering. To address this, we’ve added a new code path that is used when the HeatMap is already gridded and the data is contiguous with respect to the x- and y-axis factors.

Example

import numpy as np

arr = np.ones((10, 12)) * np.arange(12) * np.atleast_2d(np.arange(10)).T
hm_data = (list(map(str, range(12))), [chr(65+i) for i in range(10)], arr)

hv.HeatMap(hm_data) * hv.Points([('0', 'A'), ('11', 'E'), ('12', 'F')]).opts(color='red')

ToDo

• Fix hover support
• Ensure invert_axes is handled correctly
• Ensure invert_xaxis and invert_yaxis are handled correctly
• Add tests

Observations

In implementing this I found a fairly undesirable behavior of our axis range/factor calculations. Specifically because we accumulate the ranges by element type the ordering of factors is not preserved correctly if there is a layer above and below that are of the same type.

As an example here we have Points * HeatMap * Points:

hv.Points([('-1', '@')]) * hv.HeatMap(data) * hv.Points([('0', 'A'), ('11', 'E'), ('12', 'F')])

because the factors of the Points are jointly calculated we end up with the x-axis order starting as [-1, 0, 11, 12, ...] rather than the [-1, 0, 1, 2, ...] ordering you'd expect if you calculated the element factors in sequence. In this case, this causes the heatmap to be non-contiguous, disabling the optimized codepath.