Extremely slow connecting to UltraVnc server

[GoogleCodeExporter]

What steps will reproduce the problem?
1. wifi is obviously much better, but it works fine once connection is 
established
2. using latest build of ultravnc

What is the expected output? What do you see instead?
quicker connection to server, it isn't a data alone connection problem 
since the app refreshes and works fine once established.

What version of the product are you using? On what operating system?
081205 vnc-viewer and ultravnc 1.05 connecting to winxp 32 and winxp 64 
machines.

Please provide any additional information below.

Original issue reported on code.google.com by madcap1...@gmail.com on 27 Dec 2008 at 3:18

[GoogleCodeExporter]

I agree.  It is slow to grab that first frame.  I use UltraVNC 1.0.5 on XP for
development.  I believe this to be more of a hardware constraint than a software
issue.  I'm not sure if there is anything that can be done to improve this for 
a G1.

Original comment by James.Mo...@gmail.com on 9 Jan 2009 at 2:00

[GoogleCodeExporter]

Well the last build is definately better, wonder if it is due to the lastest 
builds
of UVNC or from the android viewer.  Not great great but it is definately 
usable now
( i was waiting 45 seconds before and it is probably 10 seconds now..maybe less

Original comment by madcap1...@gmail.com on 26 Jan 2009 at 4:18

[GoogleCodeExporter]

The first frame downloads very slowly for me as well. I did some digging and 
recorded the byte stream between the AndroidVNC client (version 12, Android 
2.1) and the TightVNC server (version 1.3.9, Debian 5.0.5).

I found that the client sends a SetEncodings request to the server *after* it 
sends the first FramebufferUpdateRequest, which means the server sends a 
FramebufferUpdate reply using the default, uncompressed "Raw" encoding. My VNC 
desktop is 1024x768, using a 6 bpp pixel format, so the server has to send 768 
KB just for the first frame! For a larger desktop or a higher color depth, it's 
even more data than that. This is despite the fact that my VNC desktop is about 
95% solid black (only the cursor and the bottom panel are not black).

The fix shouldn't be too complicated to make; the client just has to send the 
SetEncodings request before the initial framebuffer update request instead of 
after it.

Here is the trace. The handshake bytes are left out for clarity. Lines starting 
with "C" are from the client, and "S" are from the server. Lines with # are my 
comments/notes. Byte values are in hexadecimal.

# SetPixelFormat
C: 00 00 00 00 08 06 00 01 00 03 00 03 00 03 04 02
C: 00 00 00 00

# FramebufferUpdateRequest
C: 03 00 00 00 00 00 04 00 03 00

# FramebufferUpdate
S: 00 00 00 01 00 00 00 00 04 00 03 00 00 00 00 00

# framebuffer data (Raw encoding, 1024 * 768 = 786432 bytes)
S: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
S: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
.
.
.
# framebuffer data truncated for clarity

# SetEncodings (ZRLE, Hextile, zlib, CoRRE, RRE, TightLastRect, DesktopSize)
C: 02 00 00 07 00 00 00 10 00 00 00 05 00 00 00 06
C: 00 00 00 04 00 00 00 02 ff ff ff 20 ff ff ff 21

# FramebufferUpdateRequest
C: 03 01 00 00 00 00 04 00 03 00

# FramebufferUpdate (first rectangle is in Hextile encoding)
S: 00 3f 00 03 00 f2 01 13 01 e2 01 3a 00 00 00 05
# framebuffer data (Hextile)
S: 0e 3f 00 0b 34 06 26 00 46 10 96 20 e6 06 f6 00
S: 87 02 c7 02 4a 10 9a 20 fa 00 08 04 06 10 27 02
.
.
.

Original comment by abb...@gmail.com on 1 Aug 2010 at 5:25

[GoogleCodeExporter]

Thanks for finding that synchronization issue

Original comment by googlec...@antlersoft.com on 2 Aug 2010 at 8:15

• Changed state: Accepted

[GoogleCodeExporter]

How move setEncodings() from processNormalProtocol() to 
doProtocolInitialisation().

Reference: TightVNC Java VncViewer
http://vnc-tight.svn.sourceforge.net/viewvc/vnc-tight/trunk/java/src/com/tightvn
c/vncviewer/VncViewer.java?revision=3658&view=markup

Original comment by k3ju...@gmail.com on 23 Mar 2011 at 8:27

[GoogleCodeExporter]

I've faced same issue while using with ultraVNC, but seems this not yet 
resolved in newest build 203...

Original comment by vivimil...@gmail.com on 4 Oct 2011 at 1:48