I'd like to use cotvnc 2.0b3 because of the nice connection manager, but I'm finding that cotvnc is much slower than VNCViewer by Robert Kedoin. I've tried cotvnc with RealVNC server and TightVNC server (both running on a PC), and in both cases, cotvnc is slower than VNCViewer connecting to the same servers. I've tried varying the compression protocols in cotvnc, but I see no obvious difference in performance. Color depth is set to 4096 colors or less in cotvnc (just like how I have it set in VNCViewer).
Yes, I have the exact same problem. Nothing runs faster than using tightvnc's own command-line viewer. cotvnc is very laggy, on my Powerbook 1.6 Ghz. Plus, cotvnc has no way to set quality and compression levels.
Further, I use tight at low quality levels quite a bit, and I can't do that at all in cotvnc.
for me cotvnc to windows xp with tightvnc server and ultravnc server is completely unusable.
Sometimes I get the mouse moving, most of the time maybe for 1 or 2 seconds. Then it stops and I have to wait and refresh and wait and maybe I get another 1-2 seconds. From the same machine I can use tightvnc from fink and the connection is flawless.
Have tried with many different profiles to no result. I keep on coming back for new versions in the hope to find this a usable alternative but sadly for now it's still a total no-no for me.
I've been trying to use CotVNC on a gigabit LAN between 2 fast machines. I set the encoding to RAW which should be fastest on a gigabit network but it's excruciatingly slow.
Digging into the code a bit, as far as I can tell there is a major performance problem with reading from the network. The code utilizes readinbackgroundandnotify to read the socket data, but it only reads 510 bytes at a time, and seems to cause the program to spawn dozens of threads per second just to read the network data?? I checked it with a sampling in the activity monitor and it looks like this is exactly what's happening.
I suspect it affects all the encodings not just RAW but I'm not sure how to fix it.
I ended up digging into the source code more and I found a simple way to "fix" it. It's probably not ideal - I've never coded Obj-C but it works for me.
After doing more extensive testing it looks like my dual G5 2.0ghz was CPU-limited on 1.5MB/s of VNC data. This was slowing things down horribly on my GigE LAN and even slowing down some remote connections considerably. It's much faster now, I have a very high refresh rate and CotVNC can utilize > 50MB/s(!) on my LAN (Raw encoding).
I don't think the patch is quite suitable for general distribution yet but if anybody wants to test feel free to drop me a line (firstname.lastname@example.org).
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.