Fix heatmap rendering when zsmooth=fast - #6565

Thanks for the PR.
To compare here is the updated codepen based on your PR:
After vs Before.

To lock down the issue, please add a jasmine or image test.
You could use this simplified codepen.

Ok, I will try to cover both the edge case (when the bug can be visualized) and the other case (invisible, which affects performance).

Do you know by the way why the build-and-test checks failed ? It seems to fail randomly on "webgl-jasmine" or "flaky-no-gl-jasmine" from what I saw (one succeeds, the other fails) but unless I missed something it should not be related to this PR.

Thanks. Those failures are common and are not related to your PR. I will rerun those two tests for you.

Ok thank you.

To better illustrate what I mean by "edge case" (visual bug) vs "other case" (performance issue) : most of the time (when m*n is less than imageWidth*imageHeight) there will be a lot of dead pixels drawn outside the canvas, hence this is invisible but impacts performance :

To "see" it, on current master :

// if(zsmooth === 'fast') {
//     canvasW = n;
//     canvasH = m;
// } else {
//     canvasW = imageWidth;
//     canvasH = imageHeight;
// }
canvasW = imageWidth;
canvasH = imageHeight;

And with return [0, 0, 0, 1]; instead of return [0, 0, 0, 0]; in setColor,

Inspecting the final image of "zsmooth_methods" mock reveals how many (181x3 instead of just 5x3) pixels were drawn :

In fact I was trying to find a way to improve heatmap rendering performances both with and without zsmooth and I land on this bug :).

Currently we have a bug in our image test system.
To avoid that please rename your new mock & baseline png (as well as in the jasmine require) from
heatmap_small_layout_zsmooth_fast to ``zz-heatmap_small_layout_zsmooth_fast`.
That way the order of baseline creation won't change in parallel runs and we should be good to go.
Thank you!

Thanks very much for the great fix and tests! 🥇
💃

Thank you for your responsiveness !