JPEG decoder slow on Firefox

[CendioOssman]

Describe the bug
Servers using the new JPEG encoding from RealVNC runs much slower than those using the Tight JPEG encoding. The issue only affects Firefox, not Chrome.

To reproduce
Steps to reproduce the behavior:

1. Connect to VNC server using JPEG encoding
2. Do something that generates a lot of updates
3. Everything gets sluggish and memory usage spikes

Expected behavior
Performance similar to Tight JPEG or better.

Client (please complete the following information):

• OS: Fedora 42
• Browser: Firefox
• Browser version: 142

Server (please complete the following information):

• noVNC version: 4cb5aa4
• VNC server: TigerVNC with RealVNC JPEG support
• WebSocket proxy: websockify

Additional context
Issue reported to Firefox here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1986619

[CendioOssman]

I tried to optimize things here, but ended up making it worse:

https://github.com/CendioOssman/noVNC/tree/jpegopt

[CendioOssman]

The main issue seems to be when we search for the end of image data:

noVNC/core/decoders/jpeg.js

Lines 119 to 135 in 4cb5aa4

	let extra = 0;
	if (type === 0xDA) {
	// start of scan
	extra += 2;
	while (true) {
	if (sock.rQwait("JPEG", length-2+extra, 4)) {
	return null;
	}
	let data = sock.rQpeekBytes(length-2+extra, false);
	if (data.at(-2) === 0xFF && data.at(-1) !== 0x00 &&
	!(data.at(-1) >= 0xD0 && data.at(-1) <= 0xD7)) {
	extra -= 2;
	break;
	}
	extra++;
	}
	}

We keep refetching data a lot there.

[CendioOssman]

This alternative reduces the number of calls, but still has poor performance:

        let extra = 0;
        if (type === 0xDA) {
            // start of scan
            if (sock.rQwait("JPEG", length-2 + 2)) {
                return null;
            }

            let len = sock.rQlen();
            let data = sock.rQpeekBytes(len, false);

            while (true) {
                let idx = data.indexOf(0xFF, length-2+extra);
                if (idx === -1) {
                    return null;
                }

                if (idx === len-1) {
                    return null;
                }

                if (data.at(idx+1) === 0x00 ||
                    (data.at(idx+1) >= 0xD0 && data.at(idx+1) <= 0xD7)) {
                    extra = idx+2 - (length-2);
                    continue;
                }

                extra = idx - (length-2);
                break;
            }
        }

[CendioOssman]

I've added 23b7219 and 356eab4 which reduces the issue by quite a bit. But there is still some odd memory leaking remaining that is causing performance hiccups. I'll keep this issue open for a bit longer and see what Mozilla can find.