Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am running tightvnc. On both the server and client I used -depth 8.

Despite this, when I start the session, the viewer program at the client prints this information which seems to indicate that 32 bits will be used. Is there an explanation for this, please?

VNC server default format:
  8 bits per pixel.
  True colour: max red 7 green 7 blue 3, shift red 0 green 3 blue 6
Using default colormap with is TrueColor.  Pixel format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0

I am using the desktop version of Ubuntu 10.10 (Maverick) on both the server and client. TightVNC is version 1.3.9 on both ends. I believe the newer version, 2.x, is Windows only as of today except the client JVM version. I am not using the client JVM version, which is also 2.x, because I do not know if it is compatible with 1.3.9 on the server.

The invocations are:

vncserver -depth 8 -geometry 800x600 :1
vncviewer -depth 8 -noshared -nocursorshape 255.255.255.255:1
share|improve this question
    
I have not observed the data your showing before, but the purpose of transmitting the data as 8bit , is to reduce the quantity of data (as you know) needed to transfer to the client end, the data received will be 8bit, but it can still be on (and/or from) a display that is 8bit 16bit 24bit or 32bit. As long as the speed of sending less data was all ok, thanks to sending only an outline of the data :-) I never bothered to look beyond that. –  Psycogeek Apr 11 '12 at 6:49
    
The speed is not okay and that's why I am asking. Repaints are slow. Of course there are other bottlenecks at the moment because I'm forced to use WiFi through a brick wall but I will look to fix my ethernet. If I can go from 32 bits down to 8 that would be good. –  broiyan Apr 11 '12 at 8:14
    
I am adding more info to the post. –  broiyan Apr 11 '12 at 11:49
    
It would be helpfull to know what OS it is? Which version or implementation of tight? mabey the parameters are not correct? -encoding hextile -compresslevel 1 -quality 5 /8bit * <---mabey try that slash instead of the minus sign? In ubuntu they use *-depth 8 -pixelformat BGR233 -cc4 in windows it can be -compresslevel 9 -nojpeg -8bit –  Psycogeek Apr 11 '12 at 11:53
    
@Psycogeek, This -pixelformat bgr233 on the server and -bgr233 on the viewer "solved" the mystery. It now claims to be using 8 bits. Thanks. You should write this as the answer. –  broiyan Apr 11 '12 at 12:06
show 1 more comment

2 Answers

Also try this:

on vncserver use -depth 32
on vncviewer use -bgr233

If using bgr233 on the server as suggested by Psycogeek, applications running on the server may use dithering to improve their appearance. KDE, for example, does this. Dithering patterns, especially the irregular patterns produced by the "error diffusion" method, do not compress well and slow down transmission.

The test below with a KDE desktop shows that the amount of data transferred over the network is smallest if the server runs in truecolor mode (depth 32; depth 24 may also work well but I didn't test this) and the client requests bgr233 colors. The server then "rounds" colors to those available in the bgr233 palette, resulting in homogeneous areas that compress well.

Depending on vnc versions, settings and connection type, it can also be advantageous to run the vnc connection over a compressed ssh connection:

ssh -C -L 5901:127.0.0.1:5901 user@remote

(connecting to localhost:1 instead of remote:1 with vncviewer) and/or to tune the list of vnc compression methods with "vncviewer -encodings".

Test

To obtain statistics on the amount of data transferred, I run ssh -C with -v. This prints stats at the end of the ssh connection (ctrl+d) that show the amount of data sent by vnc and to what amount ssh could compress it.

On the vnc server, I run KDE at 1440x800 with a standard desktop of OpenSUSE 12.2. The OpenSUSE desktop includes a desktop folder in a corner with a semi-transparent background and a gradient light effect. The folder contains a few icons. Furthermore, there is a launch panel. For each test, I start an ssh connection with -C -v, connect with vncviewer, close the connection after the desktop is completely transmitted and ctrl+d the ssh connection to read the stats. To use standard vnc settings despite connecting to localhost, I use vncviewer with -encodings "copyrect tight hextile zlib corre rre raw". In a 2nd test, I omit "tight". Finally, I also test with the default localhost settings. I repeat all tests with a solid desktop background color, but not a pure white or other color available in the bgr233 palette.

Results

(1) Background picture "Evening" by Christoph Kummer (shipped with OpenSuSE 12.2):

with "tight" encoding:

32 bit server + bgr233 client: raw data   231,129, compressed   231,195
16 bit server + bgr233 client: raw data   235,528, compressed   235,548
bgr233 server + bgr233 client: raw data   379,472, compressed   379,524
16 bit server + 16 bit client: crashes xvnc server
32 bit server + 32 bit client: crashes xvnc server

without "tight" encoding:

32 bit server + bgr233 client: raw data   514,614, compressed   336,993
16 bit server + bgr233 client: raw data   526,267, compressed   343,430
bgr233 server + bgr233 client: raw data 1,122,449, compressed   440,477
16 bit server + 16 bit client: raw data 3,422,711, compressed 1,486,065
32 bit server + 32 bit client: raw data 4,620,578, compressed 2,806,274

with "localhost" settings:

32 bit server + bgr233 client: raw data 1,153,388, compressed   231,740
16 bit server + bgr233 client: raw data 1,153,397, compressed   236,428
bgr233 server + bgr233 client: raw data 1,153,695, compressed   380,015
16 bit server + 16 bit client: raw data 4,612,015, compressed 1,166,199
32 bit server + 32 bit client: raw data 4,611,296, compressed 2,805,144

(2) Solid color background:

with "tight" encoding:

32 bit server + bgr233 client: raw data    10,151, compressed     9,862
16 bit server + bgr233 client: raw data    14,994, compressed    14,817
bgr233 server + bgr233 client: raw data    76,335, compressed    76,268
16 bit server + 16 bit client: crashes xvnc server
32 bit server + 32 bit client: crashes xvnc server

without "tight" encoding:

32 bit server + bgr233 client: raw data    28,285, compressed    15,885
16 bit server + bgr233 client: raw data    40,597, compressed    25,410
bgr233 server + bgr233 client: raw data   460,902, compressed    93,067
16 bit server + 16 bit client: raw data   161,323, compressed    73,196
32 bit server + 32 bit client: raw data   152,342, compressed    78,657

with "localhost" settings:

32 bit server + bgr233 client: raw data 1,155,743, compressed    14,926
16 bit server + bgr233 client: raw data 1,153,388, compressed    19,015
bgr233 server + bgr233 client: raw data 1,153,379, compressed    77,238
16 bit server + 16 bit client: raw data 4,611,296, compressed    62,929
32 bit server + 32 bit client: raw data 4,611,296, compressed    74,081

Discussion

Note that 1440 x 800 = 1,152,000 and times 4 this is 4,608,000. In "localhost" mode, vnc seems to send uncompressed data. The choise of desktop background and the server color depth make no difference. Also, vnc seems to use 32 bit per pixel for transmission even in 16 bit mode. Nonetheless, there are differences how well ssh can compress the data stream.

In all cases tested, bgr233 on the client receives the smallest amount of data if the server runs with 32 bit colors, closely followed by 16 bit colors and much higher amount of data if using bgr233 also on the server. The effect is most pronounced with the solid background.

With the picture background, the "tight" encoding and localhost + ssh compression produce similar results for a bgr233 client. This suggests that "tight" uses zlib compression (which is similar to the compression ssh uses) in these settings.

In the 16 and 32 bit client settings, the server unfortunately crashes when "tight" is used. These would be the settings in which the jpeg compression supported by "tight" would be useful, especially with the background photo.

Caveat: The results suggest that ssh compression with localhost default settings works well. However, the test does not include typical desktop use such as scrolling a long page in a web browser for which the "copyrect" encoding may be important.

In addition, ssh compression may add a noticeable delay in a fast connection, resulting in a connection that feels slow despite excellent compression.

-JJ

share|improve this answer
add comment
up vote 1 down vote accepted

The answer thanks to Psycogeek is:

on vncserver use -pixelformat bgr233
on vncviewer use -bgr233

Once these options are added, the viewer claims to be using 8 bit pixels. I'm not going to bother to ask why the -depth 8 is not sufficient because it's free software.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.