On 12/22/11 2:41 AM, Peter Åstrand wrote: > I'll let Pierre give you the details of the -DeferUpdate values, but if > it turns out that it's not possible to find a default that fits > everyone, then I'm suggesting that we create a special script > "turbovncserver", "vglvncserver" or something like that. It can then > have defaults that are optimal for the 3D-on-LAN case.
Except that that still requires a user to explicitly do something different on the server than they would normally do, and users forget to do that. Maybe there is no way to reconcile the differences between 2D and 3D apps, but we haven't really tried. I've provided tons of data regarding 3D and video app performance, but the equivalent data does not exist for 2D apps, so we really don't know what's best for those apps, and we can't make that judgment just based on gut feelings or quick & dirty benchmarks. We need something more quantifiable. Ultimately, if TigerVNC decides not to be performant by default for 3D apps, then so be it, but I want that decision to be justified based on solid data. TurboVNC will continue to move forward and focus on peak 3D app performance and 3D-specific features, but my preference would be for people to make the choice of Turbo vs. Tiger based on features and not performance. I really want the solutions to be fully interchangeable, as much as possible. It's really easy for me to document something to the effect of "use TigerVNC with compression level 1 to get TurboVNC-like performance", but as the number of steps required to obtain TurboVNC-like performance increases, it starts getting more and more difficult to document and more prone to user error. The problem with performance issues is that they aren't like hard errors. People will notice a drop in performance, but they won't assume that there is any way to improve it, so you don't really hear about performance issues until you get beaten up in the press. > Btw, wrt the latency work, we have done extensive testing, and it turns > out that Pierres work gives a huge improvement. Common usage cases such > as writing text in OpenOffice is now much faster on high latency links. > The typing "lag" is basically gone. I don't know about that-- I certainly still see a lag when typing (I mean, latency is still latency, and the time between typing a character on the screen and seeing it on your client is still equal to RTT), but the extensions have definitely eliminated the latency-dependent update rate cap. The extensions allow you to now "type ahead" of the latency, which makes it less apparent, but I can still feel it on a 200 ms connection. What is the status of getting the extensions "officially" adopted as part of the RFB spec? ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
