You might not notice much difference, depending on the type of
application you're using. TigerVNC uses a high-performance variant on
Tight encoding developed originally by yours truly for TurboVNC. Tight
encoding attempts to encode subregions of the remote display using the
most efficient method possible. VNC, in general, sends "framebuffer
updates" from server to client, and each of those updates can contain
one or more "rectangles." A rectangle is just a set of coordinates for
a region of the remote display, followed by encoded image data for that
region. The simplest framebuffer update would be a single rectangle
encompassing the entire remote display-- this is called a "full
framebuffer update" and is sent when the client first connects, but
subsequent framebuffer updates are most often "incremental" and contain
a set of rectangles representing the areas of the remote display that
have changed since the last full framebuffer update.
For each rectangle, the Tight encoder first analyzes it to see if a
significant portion of it can be represented with a single color. If
so, then the encoder encodes that subrectangle as a bounding box and a
fill color (this is called "solid subencoding.") For the remaining
subrectangles, the Tight encoder counts the number of unique colors in
them. If the rectangle has only two unique colors, then it is encoded
using a 1-bit bitmap and a 2-color palette ("mono subencoding.") If the
rectangle's color count is less than the "palette threshold" (in
TigerVNC, this is 24 for Compression Level 1 and 96 for Compression
Level 2 and up), then it will be encoded using an 8-bit bitmap and a
palette with up to 24 or 96 colors ("indexed color subencoding"). If
there are more unique colors than that, then the subrectangle is encoded
using JPEG subencoding (if JPEG is enabled in the settings, which it is
by default) or raw subencoding (if JPEG is not enabled.) Raw
subencoding sends the raw pixels from the server's virtual framebuffer.
Subrectangles encoded using raw (if enabled), indexed color, or mono
subencodings are all compressed with Zlib prior to transmission.
I explain all of that to explain this: Adjusting the Compression Level
in TigerVNC affects the following things:
-- Higher compression levels increase the level of Zlib compression, but
this only affects raw, indexed color, or mono subrectangles. If you are
using an application that generates images with a lot of unique colors--
like a game or Google Earth or a photo editor or even a web browser
viewing a photo-intense web page-- then most of your subrectangles may
end up being encoded as JPEG, in which case the Compression Level
setting will have little effect. You should instead lower the JPEG
Quality to reduce your bandwidth consumption.
-- By default, Compression Levels 2 and higher enable the Comparing
Update Tracker on the server end, whereas Compression Level 1 doesn't
(but you can override this by passing an argument to the server when you
start it.) The Comparing Update Tracker uses more server CPU time
(10-15%) but prevents duplicate framebuffer updates generated by
ill-behaved applications from being sent to the VNC viewer(s).
-- As previously mentioned, Compression Level 2 has a higher palette
threshold than Compression Level 1, so it will tend to favor the use of
indexed color subencoding over JPEG subencoding moreso than Compression
Level 1. That may lower the bandwidth consumption for some
applications, particularly if they tend to produce images with low
numbers of unique colors.
-- When using certain applications, you may notice a marginal reduction
in bandwidth consumption by moving from Compression Level 2 to
Compression Level 5 or 6, but not in all cases. Applications that
generate high numbers of unique colors, for instance, probably won't
benefit much if at all. Generally Compression Level 2 has the best
"bang for the buck", although those looking for the best performance in
a high-speed network environment should consider Compression Level 1
instead. Generally, CL 1 and CL 2 trade off CPU usage for network
usage, and the difference is, on average, in the ballpark of 20-40%
Although technically supported by the TigerVNC server, compression
levels higher than 6 should never be used. In no case have these higher
compression levels been shown to improve bandwidth consumption, and they
increase CPU usage by as much as 4-5x.
On 1/30/14 6:46 PM, BonnieZ wrote:
> Hi all,
>
> Is anyone familiar with how compression works in TigerVNC? If not
> specified, what's the default compression?
>
> I was doing some bandwidth tests with different levels of compression
> and the default, and I didn't notice much difference with or without
> compression.
>
> Thanks,
> Bonnie
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Tigervnc-users mailing list
Tigervnc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-users
