RGB24 failing on Web Server, no display

[Westworld]

Tested with 2.2.0 and 2.2 release 11
The web server (based on web Socket), such as localhost:9090, works fine for reduced color mapping, but fails with rgb24 frames.

They are send, and inspector shows packages arriving, but web area remains black.
Inspecor/Console shows debug messages such as
Colored rgb24 Frame: 41978 from renderRgb24 / main.js 249
so packages are arriving.

[Westworld]

Oops, it seems that you did not included that on purpose, because the traffic for uncompressed rgb24 is too heavy, right?
If yes, please just close this request, I assume that would be a feature request like support for rgb565 or similar to reduce the bandwidth? And I guess nobody else needs that...

For testing I have modifed main.js line 248-250:
renderRgb24(data) {
//console.log('Colored rgb24 Frame: %s', frame.timestamp);
if (!this._clientStart) {
this._clientStart = new Date().getTime();
this._serverStart = data.timestamp;
}
var serverDiff = data.timestamp - this._serverStart;
var clientDiff = new Date().getTime() - this._clientStart;
var delay = this._bufferTime + serverDiff - clientDiff;

	if (delay < 0) {
		this._bufferTime -= delay;
		console.log("Increasing buffer time to %sms.", this._bufferTime);
		delay = 0;
	}

	var that = this;
	setTimeout(function () {
		that._dmdMesh.material.map.image.data = data.planes;
		that._dmdMesh.material.map.needsUpdate = true;
		that.renderCanvas();
	}, delay);
},

Now the browser displays RGB24, such as Tron (with Serum) or tables using Flex such as JP's Dreadpool.
The display is reversed on y-axes, the planes seems not to fit for the renderCanvas() function.

Browser works for a while, sometimes some seconds, sometimes up to a minute, then freeze (I test using Wifi).
I also tested by using ESP32 to feed a 256x64 display and while that worked fine for many minutes, the device is too slow to follow up the fast animations in Tron, sometimes display is 1-3 seconds behind real time. it is not the DMD hardware, I tried to skip frames when I'm behind, it is the Wifi receiving part. The browser test proves that your web socket server is fast enough to send, that it fails on receiver side.

To solve that, either the Web Socket Server would need to compress RGB24 frames (such as RGB565) or skip frames (if there are more than 20-25 fps), to reduce bandwidth, which is a little bit extrem request.
My DMD panels are a little bit slow (icn2053), this leads to serial port hickups (when using the ZeDMD interface), so I thought Wifi could be a solution.
Workaround lead to workaround, remaining idea would be to use a Teensy with Ethernet cable, fetching Web Socket packets, compressing them and sending (left + right panel separated) via serial port to two ESP32 feeding the panels. Crazy setup.
I assume best to trash those panels and give up...

As said, I guess best to close this and keep RGB24 unsupported for WebSocket.

[freezy]

Cool, can you open a PR for this, then I see what I can do in terms of compression.