Use canvas instead of CSS gradient for liveview

[zanhecht]

Allows for "pixel perfect" liveview instead of diffused view, to better match what's shown at https://kno.wled.ge/features/effects/. This will make it easier to see what the LEDs are doing, although it may not be as accurate a representation for installations with diffused LEDs. Includes fallback to CSS gradient method for browsers that don't support canvas. Replaces #3620.

[blazoncek]

Thanks. For some reason this does not work on Firefox 115.6.0esr on mac.
Though it supports canvas.

[zanhecht]

I can't test on Firefox for Mac, but I updated it so that it's working now on Firefox for Windows and Firefox for Android. I'm also now using try/catch to fall back to the gradient method if something doesn't work.

[blazoncek]

Now it is working. 👍

[blazoncek]

I am postponing (for a short while) to consider if the increase in code size is worth the benefit.
@Aircoookie & @softhack007 can you also take a look?

[zanhecht]

The size increase would likely be negligible if I the legacy CSS gradient code were removed (not sure on the exact numbers after minimization). I think Canvas support is actually more widespread than CSS gradient support with older browsers, so that fallback may not be needed.

[blazoncek]

MDN documentation indeed shows that <canvas> may have greater support. So it may indeed be better to strip linear-gradient code from source.
BTW <canvas> is already used for 2D peek.

[blazoncek]

Tested again, but now I see these weird gaps in the peek preview.

The LED count is 512. Still less than max. possible size.

[zanhecht]

I'm not seeing that in my browsers, but it's got to be a rounding error. Easiest fix would be to change 4 * w on line 31 to 4 * Math.ceil(w). That width is an approximation anyway, as long as there's overlap it should look fine.

Another fix would be to cap the number of LEDs shown to the pixel width of the canvas, which would also have the benefits of reducing aliasing artifacts and improving performance, but I'm not sure if truncating the display is something that you want. The code would look something like the following, but I'd need to run more test cases on it:

    function draw(start, skip, leds, fill) {
      c.width = d.documentElement.clientWidth;
      var len = Math.min((leds.length - start) / skip, c.width) 
      var w = c.width / len;
      for (i = 0; i < len; i++) {
        ctx.fillStyle = fill(leds, (i * skip) + start);
        ctx.fillRect(i * w, 0, w + 1, c.height);
      }
    }

[blazoncek]

MAX_LIVE_LEDS is 256 for JSON format and ESP8266. For websockets it is 1024 on ESP32.
So there may be 1024 LED data at any time.

[blazoncek]

Tested with Math.ceil()and it does fix gap (but not used in line 31 but line 28 instead).
However, the problem is, that only about 2/3 of the strip are rendered on 1920 display.

[zanhecht]

@blazoncek Yeah, putting Math.ceil() in line 28 is going to make each stripe too wide, so everything won't displayed. Putting it on line 32 in the 4*w spot just makes the stripes overlap to eliminate gaps and rendering errors.

The fix you made is going to round the start position of each rectangle, which means that on smaller screens anything that rounds down is going to overwrite the previous stripe.

For example, I have mine set to display the colors from the C9 palette:

With your code, emulating a mobile screen that's 915 pixels wide, aliasing occurs:

With the code as I had submitted it, with the Math.ceil(w) on line 31, there is some aliasing, but not the huge bands of color:

And for reference, the code that limits the number of LEDs displayed to the pixel width of the canvas would look like: