On 2/22/11 5:57 AM, Pierre Ossman wrote: >> (2) The ability to drive different clients at different frame rates (a >> per-client image queue with frame spoiling accomplishes this.) >> >> RFB Continuous Updates solves (1) but not (2). (2) would require a >> fundamental re-architecture of Xvnc. > > To my knowledge Xvnc already does this. Change tracking and compression > is per connection.
No, you're not following the whole discussion. I need it to be able to drive clients at different frame rates *and* to send updates without incurring a round trip for each. RFB continuous updates, which will be in TurboVNC 1.1, solves (1). The existing architecture of VNC solves (2). Nothing yet solves (1) and (2). To reiterate, the reason I need (1) is that the existing architecture of VNC is very sensitive to network latency, since it incurs a full round trip from client to server and back every time an update is sent. ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
