I've played around this a bit. Nothing conclusive at this stage but here are some notes about various issues that this raised:

1. We'd want a color swatch next to the value, when applicable (e.g., in the screenshot above, tipRasterDense). Using title seems like too much of a shortcut.

2. When experimenting with custom spatial interpolators, it appears that —if possible— I’d prefer the color scale to be determined by the rasterized values rather than by the original data values. In that sense a raster interpolator feels like a transform.

With this in mind, we might want to compute the raster (in data space) as an initializer, like we do for voronoi in #1623. However, it might be tricky because the pointer will still want the untransformed index, X, and Y, if they exist.

When using a function sampler (mandelbrot), or a rectangular dataset (volcano), otoh, it would be quite slow if the transform were to create a huge index, X and Y channels, and value, then look for the closest point pixel by pixel. In that case we should directly look up the value in the derived raster.

The (1) issue you raise is related to what I raised yesterday in #1646: the reason we’re seeing the title tip here is because the data is an array of numbers (primitives). I also feel it would be better to see x and y, and fill with a color swatch. Perhaps we can somehow opt-out of the isTextual test when deriving a tip for the raster mark… (and ideally there is a way the user can explicitly opt-out of that behavior with tip: true, too, but fixing the automatic behavior is more important.)

For (2) I don’t think it will be practical to use the pointer transform as currently implemented for dense grids; I think it could add a lot of complexity. I would prefer if we could build a specialized “rasterPointer” instead that understands dense grids and does the lookup directly, and keep these problems decoupled. I also want to build continuous crosshairs.

related #1629