Changing pixelformat on the fly
jnw "at" realvnc.com
Thu Dec 23 11:36:01 2004
I'm not talking about the Tight encoding, I'm talking about the other Tight
The problem is *NOT* local cursor support. Local cursor rendering works
fine if implemented as specified in the RFB protocol document. The problem
is specifically with the TightVNC implementation of local cursor rendering,
therefore hacking your viewer to work around the bug in TightVNC by
detecting that it is TightVNC makes perfect sense.
With regard to full colour mode, it's obviously better to start with fewer
colours, since that way the initial screen contents will download reasonably
quickly, even over slow links. Over fast links, the extra time taken to
download the low colour copy before switching to full colour will be
negligible. Over slow links, the extra time taken to load a full colour
copy before immediately switching to low colour mode and downloading it
again will be prohibitive.
Given that you're not familiar with the code, nor the issues involved, I
would strongly recommend that you discuss any changes to TightVNC with Const
et al before applying modifications to their CVS.
Wez @ RealVNC Ltd.
> No pseudo-SecurityType messages are needed to enable the
> Tight encoding;
> it's just a matter of sending a normal SetEncodings message
> with Tight
> enabled. In this case, the problem is actually local cursor
> support, which
> does not have anything to do with SecurityTypes either. So I
> don't think
> that looking for a TightVNC-specific SecurityType makes sense.
> I guess we could use TightVNCs "capabilities". It would allow dynamic
> pixel format changes against RealVNC 3.X servers, but I'm not
> sure if it's
> worth the troubles. The TightVNC vncviewer4 doesn't support
> at all, currently.
> > If you report the problem to the TightVNC developers then
> I'm sure they
> That would be me. I'm the only TightVNC developer actively
> working on the
> TightVNC vncviewer4, currently.
> > > The bandwidth can change dynamically during a session. Also, the
> > > current TightVNC vncviewer4 starts off in fullcolor mode,
> unlike the
> > > RealVNC 4.0 version.
> > That's another bug you probably want to report to the TightVNC team!
> > Although, are you sure that you haven't simply overriden
> the FullColour
> > option to be true in the viewer, causing it to start in
> full colour mode?
> No, it's no bug. I've committed a patch that changed this behaviour
> yesterday. I think it makes much more sense to start in
> fullcolor mode.
> Peter Estrand Chief Developer
> Cendio www.thinlinc.com
> Teknikringen 3 www.cendio.se
> 583 30 Linkvping Phone: +46-13-21 46 00
> VNC-List mailing list
> VNC-List "at" realvnc.com
> To remove yourself from the list visit: