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.
I think we have provided quantifiable data. I agree that additional tests
would be useful though, but there are also other things that needs
attention. I think the core of the problem is there will always be some
kind of tradeoff/compromise, and if I understand the VirtualGL/TurboVNC
perspective correctly, there's no interest in this. Anything that, say,
increases the CPU, even so little, is a no-no. Given these priorities, it
seems difficult to find a solution that fits both use cases by default.
This is why I'm suggesting a wrapper script. Assuming that you will no
longer ship the file /opt/TurboVNC/bin/vncserver, users will need to learn
another path/command in any case. I don't think 3D users will find it more
difficult to learn to run, say, /opt/TigerVNC/bin/vncserver-vgl than
/opt/TigerVNC/bin/vncserver, at least not much more difficult.
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.
Of course you can never get rid of the RTT latency; that's why I said
"basically gone".
What is the status of getting the extensions "officially" adopted as
part of the RFB spec?
As far as I can tell, all extensions have official numbers.
Rgds,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
