Peter, I'm not talking about the Tight encoding, I'm talking about the other Tight protocol messages. 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. Cheers, 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 > capabilities > 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@realvnc.com > To remove yourself from the list visit: > http://www.realvnc.com/mailman/listinfo/vnc-list _______________________________________________ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
