From fdf3500843898e520ac1930ab1200f1dc37732bc Mon Sep 17 00:00:00 2001 From: DRC Date: Fri, 13 Apr 2012 10:11:15 +0000 Subject: [PATCH] git-svn-id: svn+ssh://svn.code.sf.net/p/turbovnc/code/branches/1.1.x@1973 799e4f7b-5fd2-41f6-823c-2ecc41bc7f0b --- doc/compatibility.txt | 19 ++++++++++--------- doc/index.html | 18 ++++++++++-------- 2 files changed, 20 insertions(+), 17 deletions(-) diff --git a/doc/compatibility.txt b/doc/compatibility.txt index feb7c3219..309ea00d2 100644 --- a/doc/compatibility.txt +++ b/doc/compatibility.txt @@ -78,10 +78,11 @@ TurboVNC with other VNC flavors. similarly to TurboVNC, barring the absense of multithreading in the former, but this requires using non-default settings in TigerVNC. The default TigerVNC settings are roughly equivalent to Compression Level 2 in - TurboVNC, which will produce significantly slower performance than - Compression Level 1 on 3D and video workloads. Compression Level 1 should - be used in TigerVNC in order to simulate the behavior of TurboVNC's - "Tight + JPEG" encoding methods. + TurboVNC, which will use significantly more CPU time than Compression + Level 1. Additionally, TigerVNC does inter-frame comparison by default + whenever Compression Level 2 or above is selected, and this increases CPU + time even more. Compression Level 1 should be used in TigerVNC in order to + simulate the behavior of TurboVNC's "Tight + JPEG" encoding methods. ** TightVNC or TigerVNC Viewers @@ -105,11 +106,11 @@ TurboVNC with other VNC flavors. level beyond this, except on rare corner cases (such as the console output of a large compilation) that are not performance-critical to begin with. In general, increasing the Compression Level from 1 to 2 with JPEG enabled - will increase the CPU usage for 3D and video workloads without providing - any significant bandwidth savings. However, Compression Level 2 can be - shown to reduce bandwidth for some 2D workloads, particular those with low - numbers of unique colors, by 20-40% (with a commensurate increase - in CPU usage.) + will increase the CPU usage for most 3D and video workloads without + providing any significant bandwidth savings. However, Compression Level 2 + can be shown to reduce bandwidth by 20-40% (with a commensurate increase in + CPU usage) for certain types of workloads that have low numbers of unique + colors. {nl}{nl} ** RealVNC diff --git a/doc/index.html b/doc/index.html index fd323da34..e8e0067f5 100644 --- a/doc/index.html +++ b/doc/index.html @@ -3,7 +3,7 @@ - + User’s Guide for TurboVNC 1.1 @@ -1705,10 +1705,12 @@

9.1 TightVNC or TigerVNC Servers

perform similarly to TurboVNC, barring the absense of multithreading in the former, but this requires using non-default settings in TigerVNC. The default TigerVNC settings are roughly equivalent to Compression - Level 2 in TurboVNC, which will produce significantly slower performance - than Compression Level 1 on 3D and video workloads. Compression Level 1 - should be used in TigerVNC in order to simulate the behavior of - TurboVNC’s “Tight + JPEG” encoding methods. + Level 2 in TurboVNC, which will use significantly more CPU time than + Compression Level 1. Additionally, TigerVNC does inter-frame comparison + by default whenever Compression Level 2 or above is selected, and this + increases CPU time even more. Compression Level 1 should be used in + TigerVNC in order to simulate the behavior of TurboVNC’s + “Tight + JPEG” encoding methods. @@ -1740,10 +1742,10 @@

9.2 TightVNC or TigerVNC Viewers

cases (such as the console output of a large compilation) that are not performance-critical to begin with. In general, increasing the Compression Level from 1 to 2 with JPEG enabled will increase the CPU - usage for 3D and video workloads without providing any significant + usage for most 3D and video workloads without providing any significant bandwidth savings. However, Compression Level 2 can be shown to reduce - bandwidth for some 2D workloads, particular those with low numbers of - unique colors, by 20-40% (with a commensurate increase in CPU usage.) + bandwidth by 20-40% (with a commensurate increase in CPU usage) for + certain types of workloads that have low numbers of unique colors.