At 12:05 +0100 18/4/02, you (Adrian Umpleby) wrote: > > >I've used ChromiVNC for some years and it is invaluable to me. > >That's clever! It's only just 15 months old! (Well, it was called >TridiaVNC for 3 months before that... :-)
I wrote without checking. I think I did use it as TridiaVNC, otherwise for only 1.25 years. Or maybe I was talking subjective time, like when one waits for a watched pot to boil :-). Without wanting to cast any aspersions on ChromiVNC. > >The biggest problem I have found is that it does not honour the RFB >>FramebufferUpdateRequest the way the AT&T version does. As a result, >>a slow server host can get bogged down sending updates of unneeded >>parts of the display. > >I remember Jonathan mentioning to me that he thought it was better >for the client to have the whole display at its end, even if it was >not all needed, so it was ready for the case when it scrolled into >view (or something like that...) Interesting! >Maybe that thought needs reviewing (some sort of option, perhaps?) > >Do you regularly view just a particular part of the screen? I spend more than half my time 'viewing' using a client such as x2vnc, which never displays anything from the server on the client display. So I regularly view none of the screen at all. (If you're not familiar with x2vnc, it is an X client as well as a VNC client. After connecting to the VNC server it watches the X mouse. When the mouse hits the side of the display, it grabs the X mouse and keyboard, makes the mouse pointer invisible, and starts passing mouse and keyboard events to the VNC server. When the mouse hits the opposite side of the display, it releases the mouse and keyboard and makes the pointer visible again. The effect of this is that the X display and (in my case) my laptop display appear to be contiguous, a bit like a Mac with two monitors.) I have an old, slow laptop, a powerbook 1400. On fast networks (100BaseT with switch), x2vnc works well with my laptop running chromiVNC, but on a 10BaseT network which I will have to be spending some time on, it is very slow. The AT&T server, which honours a zero-area FrameBufferUpdateRequest, responds fine on the slow network. But, as I'm sure you know, the AT&T server is not very reliable in other respects. Hence my questions on other threads about details of building both of those servers. I have thoughts of modifying ChromiVNC to honour FrameBufferUpdateRequests, or of modifying the AT&T server to be more reliable (:-). d. -- seeking employment phone +61 2 9705 9096 PGP key available NO JUNK MAIL mailto:[EMAIL PROTECTED] D A Vincent speaking for self only http://www.zeta.org.au/~dvincent "What am I expected to do? Shout 'man overboard'?" --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
