Extremely slow connecting to UltraVnc server about android-vnc-viewer HOT 6 OPEN

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.

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

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
.
.
.

Thanks for finding that synchronization issue

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

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