Sorry, I don't have any other info - that's one reason why we ended up developing our own algorithm.
We send the screen image as a series of 32 bit words that encode the content as a string of pixels top-left to bottom-right.
If (as is usually true) there are pixels unchanged from the last image we just send the number of consecutive unchanged pixels.
When there are changed pixels we send the new RGB values for those pixels. Because there are often runs of identical pixels we further compress the changed pixels by sending the count of the consecutive identical pixels (run-length encoding, or RLE).
Ie there are two kinds of 32 bit word sent:
pixels unchanged from previous image:
first byte = 0, bytes 1-3 = number of unchanged pixels
first byte = number of consecutive identical pixels
bytes 1-3 = RGB values for those pixels
Unless you want lossy compression (not good for small text om screens!), this algorithm gives you a lossless compression for typical screens that is near optimum while being easy to code and very fast to run. Eg: if the screen hasn't changed since the previous send it's just a single word (0 + number of pixels on screen). If there is just a letter or two that has changed then only the changed letters are encoded, and the RLE encoding does that very efficiently.
I found it gave a better frame rate than TeanViewer in my environment. Warning: It's not good for lots of moving images (video).