>>> Notice that, opening notepad and maximizing it to full screen then typing
>>> will cause a full window update for each char.
>
>Just curious -- I realize that the hooks will tell WinVNC that it needs to
>process the entire client area, but what kind of processing does WinVNC do
>after that to determine how much actually changed? Does it perform any
>kind of differencing operation?
I understand WinVNC does do a simple differencing operation, to determine a
smaller changed-area for transmission. ChromiVNC uses a more complex
algorithm to work out more precisely where areas have changed (see below -
I considered it necessary due to certain properties of Macintosh window
redraws). Xvnc has much more control over what is drawn where, so it
doesn't do any of this (even though it might actually help in some cases).
>Something I had considered (and WinVNC may already be doing) was that if
>the server maintained a memory storage of what had been transmitted to the
>client, then it could compare new regions to that and only send the
>differences. As a further optimization, you could have a "Delta Hextile",
>or (better) "Enable Delta Encoding" checkbox like the "Enable CopyRect
>Encoding". Then, you could BitBlt the new region against the stored region
>using the XOR RasterOp, which might even be performed by hardware in newer
>video cards. The resulting region would be black in all areas that had not
>changed, and Hextile encoding should be extremely efficient in transmitting
>that, whereas it might not be efficient re-transmitting all of the
>underlying image. Of course, the viewer would have to recognize that it
>was receiving an XOR Delta packet, and would need to use the XOR RasterOp
>as well when adding it to the screen.
Very interesting idea - it might make it's way into ChromiVNC as an
optimisation, although probably not as a separate encoding unless other
implementations adopt the new encoding.
The way ChromiVNC works is to keep a copy of whatever it sent to the
client, and a separate "modified bitmap". When the 'kernel hooks' generate
a modified region, it is marked in the "modified bitmap" and set aside.
Once the system is idle(ish) or a little time has passed (this is to allow
aggregation of multiple screen paints into a single transmission),
ChromiVNC scans the physical screen in the areas marked "modified" and
eliminates areas where the screen actually hasn't changed. It then
generates update rectangles from the reduced "modified bitmap", determines
the best compression method for each, and transmits them. At present I'm
trying to think up better ways of doing this to reduce bandwidth and/or CPU
consumption, or to trade one against the other.
All of the above is done in software, but consumes little enough CPU that
all Macs with accelerated video have powerful enough CPUs not to benefit
significantly from any hardware acceleration of the differencing process.
Even on an ancient 68040-based machine, the performance is still reasonably
comparable to, say, Xvnc on a 486 (ie. not good but tolerable). The
situation may well be different with PCs, where video acceleration was
introduced earlier and CPUs are (for general purposes) slightly less
powerful. However, the extra complexity and hardware-dependence might not
be a good thing.
Going back to XOR, it is still a good optimisation to trim off large
"blank" areas of non-changed screen for several reasons. Firstly, the
client has to allocate memory for and process a large screen area, if this
is routinely left in (consider a 1024x768 screen where only a single
DOS-box character has changed). Also, HexTile is actually not very
efficient at encoding large blank areas - it must generate at least one
byte for every 16x16 tile which is sent. RRE or CoRRE are much better for
this, but rapidly fall behind HexTile as the number of subrects increases
relative to the size of the update. Even the Zlib-based encoders probably
have *some* overhead for large blank spaces, especially if CPU utilisation
is taken into account.
--------------------------------------------------------------
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:- a20 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
---------------------------------------------------------------------
