http://www.realvnc.com/howitworks.html The VNC protocol is a simple protocol for remote access to graphical user interfaces. It is based on the concept of a remote framebuffer or RFB. In the past we have tended to refer to the VNC protocol as the RFB protocol, so you may have seen this term in other publications. The protocol simply allows a server to update the framebuffer displayed on a viewer. Because it works at the framebuffer level it is potentially applicable to all operating systems, windowing systems and applications. This includes X/Unix, Windows, and Macintosh, but might also include PDAs, and indeed any device with some form of communications link. The protocol will operate over any reliable transport such as TCP/IP.
*** Does "Remote frame buffer" rings a bell in your head ? The display side of the protocol is based around a single graphics primitive: "put a rectangle of pixel data at a given x,y position". This might seem an inefficient way of drawing arbitrary user interface components. But because we have a variety of different encoding schemes for the pixel data, we can select the appropriate scheme for each rectangle we send, and make the most of network bandwidth, client drawing speed and server processing speed. Din nefericire, nu ajuta prea mult. Atita vreme cit nu stii de fapt ce reprezinta pozele pe care le trimiti, tot degeaba. In ceea ce priveste X-ul, el stie ce reprezinta fiecare bitmap pe care il stocheaza. Exemplu : un simplu buton. Ce face VNC : prima data trimite poza butonului.Dupa ce userul apasa butonul, care apasat fiind isi mai schimba si nuantza, mai face si un "glow" , ca de, asa se poarta... ei bine, dupa ce userul apasa butonul vncul vede ca dreptunghiul continind butonul s-a modificat. Asa ca-i arde repede un jpeg (consumind un mic timp de compresie), il trimite pe retea si ajunge la viewer. Acesta mai pierde si el un timp cu decompresia jpegului, care jpeg oricum e lossy, deci imaginea produsa la viewer nu e tocmai identica cu cea originala, si re afiseaza dreptunghiul cu pricina. Ce face X : Cind iti pornesti aplicatia, cam tot ce inseamna bitmap si este deja cunoscut in momentul initializarii (deci cam tot ce inseamna element grafic de interfata - butoane, poze de pe butoane, si toate lucrurile asemanatoare) este trimis prin retea catre xserver, care le cache-uieste. Asta e partea mai dureroasa la X, prima initializare si incarcarea tuturor acestor articole. Dupa care, folosind analogia cu exact acelasi buton, pentru afisarea sa prin retea se transmite "afiseaza imaginea cu id-ul 00001 la coordonatele (x,y). Dupa ce userul apasa butonul (care stim deja ca se schimba), se transmite prin retea "afiseaza imaginea cu id-ul 00002 la coordonatele (x,y)" Desigur 00001 reprezinta imaginea cu butonul neapasat si imaginea 00002 reprezinta imaginea cu butonul apasat. De acum incolo ori de cite ori userul apasa butonul cu pricina pe retea se transmite DOAR "afiseaza bitmapul 0000N la (x,y)" Fara compresii, decompresii, fara retrimiteri de jpeguri pe retea. Datorita acestei diferente fundamentale X este MUUULT mai "snappy" si mai rapid in raspuns decit orice vnc pe orice retea. Desigur modul in care se intimpla lucrurile este un pic mai complex, dar deja nu are sens sa intram inca si mai mult in detalii. Si inca ceva : mplayer merge REMOTE si fullscreen cam cu 50-60 Mbiti pe secunda. Mai mult, traficul facut este identic in cazul in care rulezi filmul in fereastra sau in fullscreen. Explicatia este simpla : se transmit doar informatiile de afisare a cadrelor la dimensiunea lor nominala. Iar scalarea se face pe display-ul de la distanta, de catre serverul X si folosind resursele hardware ale serverului X. Cu alte cuvinte scalare la viewer (the smart way) in loc de scanare pe masina de unde pornesti tu playerul de filme. --- Detalii despre listele noastre de mail: http://www.lug.ro/
