On Fri, 2002-10-18 at 16:36, Karsten M. Self wrote: > on Fri, Oct 18, 2002, Crispin Wellington (crispin@aeonline.net) wrote: > > On Fri, 2002-10-18 at 08:15, Curtis Vaughan wrote: > > <...> > > > One thing I have noticed is the Windows VNC viewer is *crap*. During > > refreshes it will consume 100% CPU. Take two systems that are identical. > > On one put linux with a vncviewer. On the other put windows with a VNC > > viewer. Put them both on 100 Megabit ethernet. Load a programme that > > changes the screen at 60fps. On the linux client you will get close to > > 60fps updates. On the windows client you will be lucky to get 5fps. This > > is definitely due to bad coding in the Windows client. There is no > > reason why the windows client is so slow, other than its badly > > programmed. > > Is that vanilla VNC (from the old Olivetti lab in the UK, now Lucent, > soon to be defunct), or TightVNC? I find the latter tends to perform > relatively well. This is only the client I was referring too. Not the server. tightVNC Windows viewer v1.2.6 Relative to tightVNC viewer for X it stinks. The viewer for X on 100 Megabit ethernet feels like you are actually on the machine. No perceivable lag at all. On the same connection the Windows viewer feels like you are wading through mud. Try opening a full screen shell and going 'ls -alFR /' and see the refresh. Compare it to the same under the X vnc viewer. Its definately a client problem and not a bandwidth problem. The 100% CPU issue is related. I think if it was coded to use one of the higher speed Win32 gfx interfaces (like DirectX) then it would be a lot faster and use a lot less CPU. This is pure speculation without actually looking at the windows code. Kind Regards Crispin Wellington
Attachment:
signature.asc
Description: This is a digitally signed message part