My suggestion to the OP talking about compression.
First up, consider just PNG compressing the image for simplicity. It's a mostly black image with color dots. That would generally compress really well with PNG.
But also, knowing the nature of the image, you could pretty easily compress the image by doing offsets to the next pixel. The format could look roughly something like this
[offset byte, color byte, offset byte, color byte].
It will fail in cases where each pixel has a color and will excel when there is a run of black pixels (which there will be a lot of those). It's a dead simple format to implement and read as well.
You can even keep the frame around for writing. You'd just be counting black pixels left to right top to bottom, emitting that number or 255 then 0 resetting and then counting some more.
I did try a large variety of encodings and the best was delta encoding frames followed by RLE encoding similar to what you describe. It did pretty well. However, when things start to move, it only shaved ~10-20% off the size at a significant complexity and compute cost. This was before I allowed each client to have its own frame and it was more common for there to be significant areas of black.
It'd definitely be tricky to get the computational performance that you'd want out of it. I'd imagine it'd be pretty easy to accidentally bust caches.
To solve for that, you could double your frame size and store the prev/next in an alternating fashion. IE [n, p, n, p, n, p] That way when you xor you are always working with highly local memory sets. You'd want to keep the frame basically global to avoid allocating.
If you wanted to be super clever then you could probably SIMD this up doing something like [n, n, n, n, p, p, p, p]. I'm not sure how you'd turn that into RLE in SIMD. I'm not clever enough for that :D (but I'm sure someone has done it).
But as you said, complexity would definitely increase rather than decrease even though you could get much better compute time.
It also looks like half of the screen doen't change (the part that is far away fro the cursor), so compressing the xor of the new and old image would improve compression a lot.
First up, consider just PNG compressing the image for simplicity. It's a mostly black image with color dots. That would generally compress really well with PNG.
But also, knowing the nature of the image, you could pretty easily compress the image by doing offsets to the next pixel. The format could look roughly something like this
[offset byte, color byte, offset byte, color byte].
It will fail in cases where each pixel has a color and will excel when there is a run of black pixels (which there will be a lot of those). It's a dead simple format to implement and read as well.
You can even keep the frame around for writing. You'd just be counting black pixels left to right top to bottom, emitting that number or 255 then 0 resetting and then counting some more.