>Due to some braindead setup my computer was configured to use
>24 bit color depth. VNC connections were somewhat slow with or
>without restriction to 8bit on the client. CPU load was hovering
>around 50%, even when absolutely nothing was happening (no
>animations, no mouse movement, etc.).
>Now I use 32 bit color depth and CPU load has dropped to less
>than 10%. Wow!
>
>I'm using TightVNC 1.1p8c Win32 under NT SP6a on the server.
It may not be a VNC thing. Some video cards / drivers are MUCH slower at
24 bit than at 32 bit, due to the three byte alignment (misalignment?)
problem. 32bit pixels are much easier for most architectures to shuttle
around memory.
Of course, VNC doesn't have a true 24 bit mode - it uses 8, 16, and 32 bit,
and embeds 24 bit values in 32 bit pixels. This doesn't take much effort,
but (as I have discovered) any effort becomes meaningful when you are
having to process multiple megabytes of memory for every screen refresh.
I'm not sure if any meaningful benefit would arise from VNC trying to add a
true 24 bit mode... I do know that some of my nVidia TNT/GeForce drivers
wouldn't even let me select 24 bit mode because it was so much slower.
Also, restricting the viewer to 8 bit will help if network bandwidth is
your problem. If you are on a 10Mb/s or faster network, bandwidth is
almost certainly not your problem. More likely, CPU effort on the server
is the bottleneck, and can be assisted with the following:
1. 8 or 16 bit on the server (8 is much faster, but may not be tolerable,
depending on what you are doing -- graphics or video work really need 16 or
higher)
2. Don't restrict the viewer to 8 bit, because that just forces the server
to remap every pixel.
3. Use Hextile encoding. Tight, Zlib, and ZlibHex are great when you have
a modem connection, but after extensive testing at high, medium, and low
compression levels, I have found that the fastest method on my company's
moderately loaded 10Mb/s ethernet is still Hextile, due to the lower CPU
overhead. If you are fortunate enough to have 100Mb/s or (makes me drool
even to consider it) 1Gb/s connections, you definitely want to use Hextile
(actually, at 1Gb/s, it might even be worthwhile to push it through with
Raw encoding)
4. (somewhat counterintuitive) If the server is Windows 98 or later, you
may want to turn on "Show Window Contents While Dragging" in your Control
Panel / Display / Effects. This will allow dragging a window to turn into
CopyRect encodings under VNC, which is much faster. Resizing a window
becomes more painful, however, so I leave it as a judgement call.
5. Correctness issue - if the server is UN*X and you use "-depth 8", you
most likely also want to specify "-cc 3" so that it uses palettized 8bit
instead of truecolor 8bit. Most X Windows applications understand
palettized 8bit and few understand truecolor 8bit.
Also, WinVNC is very dependent on processor speed, due to the lack of a
clean way of interfacing with GDI. Xvnc is much faster even on slower
machines (Pentium 166 can play MPEGs across Xvnc with no problem, but my
Celeron 433 has trouble sometimes with WinVNC). As I say, this is not
VNC's fault, but sometimes a hotter processor can be considered a valid
expense for heavily used WinVNC servers.
Just suggestions.
_____________________________ /"\
Mac Reiter \ / ASCII Ribbon Campaign
Nomadics, Inc. X Against HTML Mail
[EMAIL PROTECTED] / \ (To join the campaign, simply use
this in your signature.)
---------------------------------------------------------------------
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
---------------------------------------------------------------------
