VNC optimized to almost 30% bandwidth raw (40% zlib)

Rudi De Vos Rudi.De.Vos "at"
Mon, 28 Aug 2000 21:14:37 +0000

If I understand the code good, the default behavior of
vncBuffer::GetChangedRegion(vncRegion &rgn, RECT &rect)
is to scan the past rect in blocks 

for (y =; y<rect.bottom; y+=BLOCK_SIZE)
------for (x = rect.left; x<rect.right; x+=BLOCK_SIZE)
-------------for (ay = y; ay < blockbottom; ay++)
--------------if (memcmp(n_block_ptr, o_block_ptr, bytesPerBlockRow) != 0)

First two for's making the (BLOCK_SIZE X BLOCK_SIZE) block move
over the full past rect "&rect"
The 3the for scans the little rect (BLOCK_SIZE X BLOCK_SIZE) and if
he find a change in the Row, the "rgn.AddRect(new_rect)" pass the place
and via a new for
for (by = ay; by < blockbottom; by++)
memcpy(o_block_ptr, n_block_ptr, bytesPerBlockRow);
the screen data is passed to the buffer.

I understand that passing 4 block's of (8x8) gives more job's and data
than passing one of (32x32).
  But when you know that the change is made from 18-24 X 32 and you only
pass that data, the number off passed rectangles stay the same.

+++Is there perhaps an other part in the code that compose back all changed
rectangles to one big and send them together to the client ?

+++Can someone test the real data passed on a network and not
the raw data statistics you get from zlib.  Perhaps this should give a
better idee if we win some bandwidth.
+++Does there exist a testsoftware for this ??

Any remarks are welcome to improve this great software.

To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at"
See also: