[K12OSN] VNCViewer and speed of refresh

[Les Mikesell]

On Wed, 2004-07-14 at 10:56, Jeff Kinz wrote:
> On Wed, Jul 14, 2004 at 10:29:07AM -0500, Les Mikesell wrote:
> > Errr..., no.  The complaint was about VNC speed over a low bandwidth
> > link.  Running straight X is going to be much worse. VNC can skip
> 
> Errr..., no.
> 
> I have used X and TightVNC over the same link, and where VNC was doing
> the typical "4-10 seconds" per screen redraw, X was mostly keeping up
> with real time.
> 
> X-windows works much better over low bandwidth links than VNC.
> 
> Why?   Raw Data vs. Abstraction

This depends very much on the screens involved.

> Remote X-windows doesn't send any graphical information over the link.
> It sends only events like "Close Window 27" to the X-server at your
> display.

Perhaps if you are talking about xterms, but what's the point of
running that remotely when you could run it locally and use ssh in
text mode at the remote?  How do you propose that mozilla might
draw a picture on your remote screen without sending all the
bits of the image?  Now imagine an X program where the graphics
change faster than they can be delivered to the remote (or
try viewing an animation over a dialup...).

> VNC, on the other hand, has to send an entire frame buffer of raster    
> data (hopefully optimized), resulting in transfers of thousands
> or tens of thousands of bytes where X sends only twenty or thirty bytes.

VNC can send whatever changed on the screen as it makes its scan and
the program keeps going even if you just see choppy snapshots at
the slow remote.  X has to wait and if the remote can't display
as fast as the program is trying to generate the images it will
just never work.

> Even with intelligently optimized 'skipping" of redraw data remote frame
> buffer systems like VNC have to send much more information over the
> network.

It takes about so many bits to represent an image any way you slice it.
X can optimize internal things but if you are really displaying graphics
there's not much it can do but push the bits.

> If VNC is more efficient, then we should use it instead of an X server
> for the thin clients right ?  Its certainly smaller than an X-Server.

No, VNC is always going to have more latency because it is only
connected to the screen buffer and doesn't know which part the
program wants to change.

> (( Historical Note - VNC was invented by some folks at Olivetti in
> the UK (Later became part of AT&T). Its designed and intended use was
> to permit people using very small systems, incapable of running an
> "X-server", to access a machine running X-Windows.

Actually in the lab where it was invented they used it routinely
on their desktops with a system that identified the users by their
lab badges and as they approached any client machine it would
automatically yank their running desktop session to them.  But,
it is kind of cute to run a remote machine from an internet-enabled
palm device (works best with a server that does scaling).

---
  Les Mikesell
    les at futuresource.com