eNut wrote:If you assume a constant 10Mb/s on the client side, which is highly optimistic, you would need to reduce that stream of data to 0.2% of the original. Even if you left out 90% of the pixels you'd still need to compress the rest to 2%. I don't think you can find *text* compressors that do that well, and text is some of the most highly compressible data there is.
Yes and no. It depends on the compression algorithm and the data being compressed. It's true that winzip compresses text data much better than video data. You also can't compress text data using a lossy algorithm, but you can with video data. For example, H264 can take a DVD-quality video stream down to 8Mb/s.
Fortunately with video data, pixels values around a given area (say an 8x8 block) are usually the same or very similar. So, you can encode the degree of difference in that block into a single piece of information that allows the decompression algorithm on the other end to reconstruct that block of pixels. The downside to compression, of course, is that is uses more CPU resources unless you can utilize dedicated encoder/decoder hardware.
This was just an example, I doubt that the same compress algorithm used for video can be utilized for this. The RDP protocol, for example, hooks directly into the graphics subsystem in windows so it gets the same events as the application does and can know what's changed on the screen without polling through video memory looking at every pixel. I think it would be much more efficient to do something similar, but hook directly into the DirectX/OpenGL APIs to determine what pixels are changing, compressing them, and transmitting them.
