> -----Original Message----- > From: Murphy Marc SLUK [mailto:[EMAIL PROTECTED] > Sent: woensdag 24 september 2003 15:00 > > We are thinking of using VAC as a remote control tool for an embedded > application and have managed to get a simulation running > under windows using > rfbcounter. The problem is that we will be initially using > the system using > a 57k link (COM port) and sending the information as 8 bit per pixel > increases our transmission requirements 8*, I see in the > future that there > will be 3bit support per pixel has there been any > consideration of using 1 > bit per pixel to support monochrome displays ?
I think it's mainly in the rfb protocol. Does that support 1 bit 'displays' or not. If it does, then best use that. If it does not, then it can be an idea to extend the protocol to also allow 1 bit displays. However, if there is no support for 1 bit (or anything below 8 bit) in the current protocol, then you also need to update the vncviewer. > > A compression algorithm would then be able to be implemented to reduce > overhead even more. If it is to optimize the bandwidth (thats what it should be) you should carefully select the compression algorithm. I think about the next parts: Go for run-length encoding. Is the most simple compression (not sending 8, the same pixels in a line but send '8 of the next pixels'). Use the fact that vnc can update parts of the screen. This can also be a single pixel. If you have a selected number of partial pictures you show (like characters or icons or such) then pre-encode those characters and send them as partial update. Keep in mind, specially if it is for display only, that there are more protocols. I think the streaming-video protocols are way to much overhead so don't spoil your time on them... > > We are looking at expanding rfbcounter to create a fairly > simple embedded > server and support 1 & 2 bit pixel modes. As the server processor is > relatively low power all complex processing can be done by the client. > > What should be done about submitting code for the client so > that changes can > be incorporated into public release ? As for the public release, to follow the gpl, copy-left license, you are free to use the rfb protocol and use the rfb-counter code as an example. If you somehow extend the rfb protocol, it is nice if you upload your ideas to the public. Specially if you update the default viewer to also view your extensions. This updated viewer code also needs to be published. And to explain your update of the protocol, it would be nice if you provide an example vncserver that shows the usage like the rfb-counter. > > Regards > Marc. > This message contains confidential information and is > intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately if you have received this e-mail by mistake and > delete this > e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free as > information could be intercepted, corrupted, lost, destroyed, > arrive late or > incomplete, or contain viruses. The sender therefore does not accept > liability for any errors or omissions in the contents of this > message which > arise as a result of e-mail transmission. If verification is required > please request a hard-copy version. > _______________________________________________ > VNC-List mailing list > [EMAIL PROTECTED] > To remove yourself from the list visit: > http://www.realvnc.com/mailman/listinfo/vnc-list _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
