>Why this is a problem? First, it makes very difficult or impossible to
>efficiently break rectangles into smaller parts depending on their
>content (not only on their size).
The Mac server currently uses FrameBufferUpdates with only one rectangle,
avoiding this problem. This involves a marginally higher overhead per
rectangle, but I don't personally think this is a major problem.
>Now about why I'm posting this message. Mostly, I'd like to know
>position of official VNC developers on described problem. I think the
>fact a server should send a number of following rectangles is a real
>problem of current RFB protocol and maybe future major versions of the
>protocol could deal with this problem in a more elegant way as
>compared to the [temporary] solution described above.
I think it's a bigger problem than you describe. Several parts of the RFB
3.3 protocol require a 'count' followed by a sequence of values, even where
(as in most cases) there is a suitable sentinel value available to
terminate the series at an arbitrary point. During RRE and CoRRE encoding,
for example, a large amount of processing is required before this count is
known, yet a suitable sentinel value could easily be provided by sending a
0x0 subrect. This is a major disadvantage to these encoding types, which
are otherwise remarkably efficient with large areas of block colour, since
this requires either a doubling in CPU utilisation or the allocation of
significant amounts of memory. The Mac server implements RRE and CoRRE by
allocating a small, fixed block of memory for them to store results in - if
this would be overflowed for a particular rectangle, the encodings cannot
be used. This block is also used for Hextile encoding, and is big enough
for even a worst-case tile to be encoded successfully.
A side-effect of this dependance on "length-plus..." constructs is that RFB
3.3 is highly intolerant of desynchronisation - there is no way of reliably
or semi-reliably picking up the flow of commands in the event of either
client or server losing track of the connection, except by forcibly
disconnecting and reconnecting.
I understand AT&T are working on RFB 4.0 or something - it will be very
interesting to see whether this addresses the above problems, without
compromising the simplicity which is so important to the VNC system.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED] (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a19 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
