Changing pixelformat on the fly

[Peter Åstrand]

On Mon, 27 Dec 2004, James Weatherall wrote:

> > I think both these solutions are ugly.
> 
> Both of these solutions assume that the bug isn't present in most servers
> (which it isn't) and therefore treat the case of a buged server as an
> exception.  

I think it's safe to assume that TightVNC users will often connect to
TightVNC servers, so I consider the case with a buggy server as pretty
common.


>Your proposed solution is a blanket disabling of local cursor
> rendering functionality for any server that uses RFB 3.7 or older, even
> though most of them can handle it perfectly safely.  

I've never suggested that local cursor rendering should be disabled. 


> The problem itself doesn't usually occur even with bugged servers,
> because pixel format changes are so rare.

When using AutoSelect on a very slow connection, there's a 100%
probability that a pixel format change will occur (since we are starting 
in full color mode). 


> As I've said previously, it's clearly not.  It results in a significantly
> longer startup time for users with slow connections (56K modem, for
> example), while providing no real benefit to users of fast networks, who can
> either let AutoSelect choose Full Colour for them or set it explicitly
> themselves.

The real benefit is real: It's about preventing a total crash of the 
vncviewer. 


> Perhaps you could wait in making these changes until you have
> established quantitatively whether they really make a difference?

No. It's more important to prevent crashes, than gain a few milliseconds 
of load time. 


>What do you mean by
> "core functionality"?  The core VNC functionality is already provided by the
> VNC codebase, surely?

I'm referring to core TightVNC functionality. For example, it should be 
possible to select JPEG compression quality, zlib compression etc from the 
GUI. Also, the Tight encoder is yet to be done. 


> > Upgrading is sometimes a very difficult procedure. We have many 
> > customers with thousands of users. They expect new clients to 
> > work with 
> > their current servers. 
> 
> Are you saying that you personally have some customers using bugged TightVNC
> servers 

Yes, many. After all, TightVNC 1.2.9 is the latest stable release, and has
been so for a while. My guess is that this is the most wide-spread
TightVNC server. 


>and that you now intend to change the TightVNC viewer to work around
> the bug rather than fix it?

Yes, I want the TightVNC vncviewer4 to be able to work with TightVNC 1.2.9 
servers, with AutoSelect, without crashing. 


> > As I 
> > said, this is 
> > only a problem for people using the new TightVNC vncviewer4 
> > against old, 
> > non-TightVNC 3.3 servers, and using very slow connections. 
> > Those users can 
> > manually force low color mode. 
> 
> No, it's a problem for anyone using your new, modified viewer over a slow
> connection to any kind of VNC Server, whether that server is Tight or not.
> What makes you think that the server version has any impact?

(I meant 3.7; not 3.3)

The automatic dynamic pixel format change is only disabled for 3.7 servers
(and earlier). Take a look at the code yourself, if you don't believe
me:

http://cvs.sourceforge.net/viewcvs.py/vnc-tight/tightvnc/vncviewer_unix/CConn.cxx?view=markup

Let me explain this once again: 

* With non-TightVNC <=3.7 servers, automatic dynamic pixel format change 
will be disabled. This is "wrong", but acceptible, IMO. 

* With non-TightVNC >3.7 servers, automatic dynamic pixel format change is 
enabled. This is correct. 

* With TightVNC <=3.7 servers, automatic dynamic pixel format change is 
disabled. This is correct, since some of these servers sends unsolicited 
FUs. 

* With TightVNC >3.7 servers (the future TightVNC generation 4 servers),
automatic dynamic pixel format change is enabled. This is correct; what we
want.


> > In the end, everything comes down to what users wants. You 
> > think that most
> > users wants something, but I think most users wants something 
> > else. We are
> > both guessing; we haven't actually recieved any user input on 
> > this issue
> > yet.
> > Users now have the freedom or choice: Either the RealVNC 
> > 4.0 viewer
> > with support for pixelformat changes against 3.3 servers, but without
> > Tight support, or the TightVNC vncviewer4 with fullcolor as 
> > default, both 
> > ZRLE and Tight support etc. 
> 
> You may be guessing but I can assure you I'm not. :)  I've personally used
> VNC over modems extensively myself and have seen various comments, feedback,
> etc from users regarding behaviour over slow links, and behaviour over
> faster links.

But those users are not using the TightVNC vncviewer4 against buggy 
TightVNC servers, right? 


Another thing to note is that all released versions of the TightVNC 
vncviewer starts out in fullcolor mode. I've never heard anyone requesting 
that the -bgr233 option should be default...

-- 
Peter Estrand		Chief Developer
Cendio			www.thinlinc.com
Teknikringen 3		www.cendio.se
583 30 Linkvping        Phone: +46-13-21 46 00