What about having a "partial screen refresh" option? The interface would have to have an escape key combination combined with mouse dragging that would allow the client to select a portion of the screen, which would then be refreshed. That should ameliorate the UDP unreliability "missing patch" problem. Perhaps a mixed UDP/TCP solution is not impossible, along the lines of a video stream (Real's RTSP uses this technique.) If a UDP-sent area of the screen goes missing for too long, a TCP message could be sent to ask for it specifically. It is even theoretically possible for the TCP connection to gauge the bandwidth and dynamically raise and lower the pixel depth of the connection (like Quicktime does) to deal with network congestion or bursts of activity. This may be too much work in this era of high-bandwidth connections - or it may be very timely in this era of huge monitor depth and resolution.
-----Original Message----- From: Frank Evan Perdicaro [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 10:06 To: [EMAIL PROTECTED] Subject: Re: vnc-list-digest V1 #1333 > Just read your notes on variable-color-depth and variable-resolution. Your > right, its way to complexed for me. My objective is to have a fast VNC > connection at the expense of color depth. I took a look at the VNC code > that manipulates palettes. Why not start by adding a 1 bit per pixel > mode (black or white) ? This would be an excellent start. Others have done some of the work. I did a tiny bit. All I can say, is please implement it and add it to the wealth that is VNC. > > As for the idea that the whole screen needs to be tracked perfectly, at > > some level of spacial, temporal, or color fidelity in order for any > > useful work to be done, I disagree. This is not how the eye works, > > and this is not how the brain works, and it is not how the real world > > works. > > I just don't buy this. If whole packets of the display are missing, you're > going to end up with big chunks of pixels that are gone...you'll get a > checkerboard effect that will force the user to do a full screen refresh, at > a much higher bandwidth cost than just getting the whole thing in TCP to > begin with. It will be flakey and unreliable, and will look "buggy". > > No, TCP isn't as efficient as UDP, but by the time you duplicate the > connection-handling and error checking features of it with UDP, you're not > going to end up with anything better. It is hard to disagree, or agree because we have different ideas of what "better" is. For low speed connections I am willing to give up color fidelty and temporal fidelity to be able to do some work. The product would be reliable if used as a tool, but not reliable in the same sense as it is reliable now. On the far, far edge of reality, it should be possible to create something like VNC that performs active analysis of the screen and converts the result to an ASCII stream. Serious image processing would be required, plus loads of huristics. But the result would be something that should work on a 300 baud line. --------------------------------------------------------------------- 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 --------------------------------------------------------------------- --------------------------------------------------------------------- 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 ---------------------------------------------------------------------
