Serve Side scaling

[Chris Smith]

> -----Original Message-----
> From: owner-vnc-list "at" uk.research.att.com 
> [mailto:owner-vnc-list "at" uk.research.att.com] On Behalf Of Greg Breland
> Sent: 21 December 2001 23:36
> To: vnc-list "at" uk.research.att.com
> Subject: RE: Serve Side scaling
> 
> 
> Actually, you would not see much of a drop in bandwidth 
> unless the page was heavy on graphics.  By scaling the the 
> screen you are compressing it and therefore, making it more 
> random.  This will cause hextile to be less effecient and 
> therefore erase your gains.  You might even slow things down 
> with the tight encoding since almost eveything will have to 
> be jpeg encoded.
> 

Incorrect.

For a "typical" environment (i.e. remote-controlling a PC), the
complexity of the screen doesn't change much, and the bandwidth required
drops significantly. Specifially -

1) For regions with complex imaging, less data is transmitted (e.g. 1
hextile instead of 4 for 1:2 scaling) so again there is a big
performance boost. [Each hextile containing a 32x32 bitmap in either
case].

2) On regions with patterns (e.g. text), the number of pixels that
differ from the background is actually reduced, again improving
performance. (As hextile uses a fixed 32x32 pixel region, the number of
tiles you transmit is reduced dramatically, more than compensating for
the increase in pixels-per-hextile).

3) Similarly to 1), for solid-colour regions, less data is transmitted
(e.g. 1 hextile instead of 4 for 1:2 scaling) [Each hextile containing
just the background colour in either case].


The point is that the scaling of the screen actually has a minimal
effect on the "randomness" of the data, and the advantages of the lower
amount of hextiles/screen data are a major bonus.

As an example, a standard Windows desktop (i.e. with taskbar at the
bottom, some icons down the left hand side, couple of medium-size app
windows open) will download in approx. 5-8 seconds over a 9600bps serial
link with PPP, compressed to 160x120 pixels (original size 800x600),
whereas the full-size desktop would take at least 40-60 seconds.

On top of this, PalmVNC only grabs the region of the framebuffer that it
needs to display, rather than the entire display (scaled or otherwise),
which gives a massive performance improvement over almost any other VNC
client (unless they've been changed to do this in the last 6 months).
Basically, it should never take more than 15 seconds @ 9600bps to grab
an entire Palm screen from the server, regardless of scaling, complexity
etc. Try doing that with a standard client (e.g. PocketPC) when the
server is 1600x1200 with complex bitmaps and apps running.


Chris.
---------------------------------------------------------------------
To unsubscribe, mail majordomo "at" uk.research.att.com with the line:
'unsubscribe vnc-list' in the message BODY
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------