Estou correndo tightvnc. No servidor e no cliente, usei -depth 8 .
Apesar disso, quando inicio a sessão, o programa visualizador no cliente imprime essa informação, o que parece indicar que 32 bits serão usados. Existe uma explicação para isso, por favor?
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
Estou usando a versão desktop do Ubuntu 10.10 (Maverick) no servidor e no cliente. O TightVNC é a versão 1.3.9 em ambas as extremidades. Acredito que a versão mais recente, 2.x, seja o Windows somente a partir de hoje, exceto a versão da JVM do cliente. Eu não estou usando a versão JVM do cliente, que também é 2.x, porque não sei se é compatível com o 1.3.9 no servidor.
As invocações são:
vncserver -depth 8 -geometry 800x600 :1
vncviewer -depth 8 -noshared -nocursorshape 255.255.255.255:1
A resposta graças a Psycogeek é:
on vncserver use -pixelformat bgr233
on vncviewer use -bgr233
Quando essas opções forem adicionadas, o espectador afirma estar usando pixels de 8 bits. Eu não vou me incomodar em perguntar por que o -depth 8 não é suficiente porque é um software livre.
Tente também isto:
on vncserver use -depth 32
on vncviewer use -bgr233
Se estiver usando o bgr233 no servidor, conforme sugerido pelo Psycogeek, os aplicativos executados no servidor podem usar o pontilhamento para melhorar sua aparência. O KDE, por exemplo, faz isso. Os padrões de pontilhamento, especialmente os padrões irregulares produzidos pelo método de "difusão de erro", não compactam bem e retardam a transmissão.
O teste abaixo com a área de trabalho do KDE mostra que a quantidade de dados transferidos pela rede é menor se o servidor for executado no modo truecolor (profundidade 32; profundidade 24 também pode funcionar bem, mas eu não testei isso) e o cliente solicita cores bgr233. O servidor "arredonda" as cores para as disponíveis na paleta bgr233, resultando em áreas homogêneas que são bem compactadas.
Dependendo das versões do vnc, configurações e tipo de conexão, também pode ser vantajoso executar a conexão vnc em uma conexão ssh compactada:
ssh -C -L 5901:127.0.0.1:5901 user@remote
(conectando ao localhost: 1 em vez de remoto: 1 com vncviewer) e / ou para ajustar a lista de métodos de compactação vnc com "vncviewer -encodings".
Teste
Para obter estatísticas sobre a quantidade de dados transferidos, executo ssh -C com -v. Isso imprime stats no final da conexão ssh (ctrl + d) que mostra a quantidade de dados enviados por vnc e em qual quantidade o ssh pode compactá-lo.
No servidor vnc, eu corro o KDE em 1440x800 com um desktop padrão do OpenSUSE 12.2. A área de trabalho do OpenSUSE inclui uma pasta da área de trabalho em um canto com um fundo semitransparente e um efeito de luz gradiente. A pasta contém alguns ícones. Além disso, há um painel de lançamento. Para cada teste, inicio uma conexão ssh com -C -v, conecto com vncviewer, fecho a conexão depois que a área de trabalho é completamente transmitida e ctrl + d a conexão ssh para ler as estatísticas. Para usar configurações vnc padrão, apesar de conectar-se ao localhost, eu uso o vncviewer com -encodificações "copyrect tight hextile zlib correra raw". Em um segundo teste, omito "tight". Por fim, também testo com as configurações de localhost padrão. Eu repito todos os testes com uma sólida cor de fundo da área de trabalho, mas não uma cor branca pura ou outra cor disponível na paleta bgr233.
Resultados
(1) Imagem de fundo "Evening" de Christoph Kummer (enviado com o OpenSuSE 12.2):
com codificação "restrita":
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
sem codificação "restrita":
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
com configurações "localhost":
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) Fundo de cor sólida:
com codificação "restrita":
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
sem codificação "restrita":
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
com configurações "localhost":
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
Discussão
Observe que 1440 x 800 = 1.152.000 e 4 vezes isso é 4.608.000. No modo "localhost", o vnc parece enviar dados não compactados. A escolha do plano de fundo da área de trabalho e a profundidade de cor do servidor não fazem diferença. Além disso, o vnc parece usar 32 bits por pixel para transmissão, mesmo no modo de 16 bits. No entanto, existem diferenças em como o ssh pode compactar o fluxo de dados.
Em todos os casos testados, o bgr233 no cliente recebe a menor quantidade de dados se o servidor for executado com cores de 32 bits, seguido de perto por cores de 16 bits e uma quantidade muito maior de dados se estiver usando bgr233 também no servidor. O efeito é mais pronunciado com o fundo sólido.
Com o fundo da imagem, a codificação "tight" e a compressão localhost + ssh produzem resultados semelhantes para um cliente bgr233. Isso sugere que "tight" usa compactação zlib (que é semelhante à compressão que o ssh usa) nessas configurações.
Nas configurações do cliente de 16 e 32 bits, o servidor infelizmente trava quando "apertado" é usado. Estas seriam as configurações nas quais a compressão jpeg suportada por "tight" seria útil, especialmente com a foto de fundo.
Advertência: Os resultados sugerem que a compactação ssh com as configurações padrão do host local funciona bem. No entanto, o teste não inclui o uso típico da área de trabalho, como a rolagem de uma página longa em um navegador da Web para o qual a codificação "copyrect" pode ser importante.
Além disso, a compactação ssh pode adicionar um atraso perceptível em uma conexão rápida, resultando em uma conexão lenta, apesar da excelente compactação.
-JJ
Tags tightvnc