I didn’t find ssvnc in arch’s extra repo or in the AUR. A bit more PKGBUILD experience and I should be able to remedy that.

But, yes, it does appear that krdc what was behind the delay. This delay (~1 s) was noticed when vnc’ing between two computers at home (not strictly lan-connected as one was a wireless laptop). Today’s case was with my work computer. Even then, vncviewer was much faster than krdc. So, clearly, krdc is at fault here. I’ll follow this up by opening another bug.

In conclusion, the final response speed was actually pretty damn fast. If the used bandwidth were less, we’d have a winner.

Anyway, I’m not sure if your 1/2 to 1 seconds per window is for distant
connections or for ones over a LAN. Considering you have the fast fb
read rate from the nvidia drivers, would make me this that is slow
if over a LAN. I did a test with a VNC connection using krdc to a machine
on my LAN and it seems somewhat slow to me. It might be the hextile
implementation or something else. Please try a tightvnc viewer, or
even better, my SSVNC contraption. It won’t be as fast as the other
protocols, but let me know if you notice an improvement over krdc.

I was actually connected to the root display at the time I took the trace. I just use -create as a matter of convenience – it’ll connect to an existing X display (if it finds one) or create one for me. That way, I can be lazy and use the same command for both usage cases. Also, true, I use the nvidia closed source drivers (sigh!).

The performance of vnc is decent, but it’s just that. At work, I use krdc to connect to multiple (Windows) computers. The performance of the remote desktop protocol is near real-time. I actually acquire images on a computer remotely and the preview in the software updates instantly. Moving, maximizing or resizing windows is seemless. It’s as if I’m actually at the remote machine.

On vnc, on the other hand, I’ve come to not expect such speeds. Granted it’s much faster than X11 forwarding over ssh, and that it’s perfectly usable (heck! I use it without complaining!), but it is still slow in comparison to rdp. A move/resize window event will typically show a delay of half a second to a second before it occurs. Previewing video-like content is pretty much right out. It ‘feels’ remote.

Hence, I described it as ‘wickedly slow’. Since I don’t think I have any problems with my configuration, you’re certainly accurate in calling me spoilt.

I’ll make the edits in the post as soon as I get more free time. Thanks for taking the time to correspond. I really do appreciate your work!

Thanks for submitting that RFE for krdc either autodetecting or having
-ycrop functionality like ssvnc.

I looked at your pastebin and I see it is using tight and/or hextile encoding:

Using tight encoding for client 192.168.1.4

Switching from tight to hextile Encoding for client 192.168.1.4

and I think that should be good, especially over lan.

BTW you appear to be connecting to a physical graphics display,
i.e. :0, and not a virtual one that -create is intended to create.
If -create finds an existing X display of yours, :0 in this case, it uses
that and does not create an Xvfb virtual one.

Anyway your read rate is very fast too (for a physical graphics card;
I suspect nvidia proprietary drivers and not those of Xorg.)

So.. I guess I’d need you to quantify ‘wickedly slow’ in terms of
timings it takes to do various activities on the desktop. Then I may
be able to know whether there is a problem with your configuration
or that you are simply spoiled

Agreed. However, I still prefer to open the tunnel explicitly. Just my preference, I guess.

I’ll attempt to characterize the slowness of the vnc connection. This test is between my desktop and my laptop at home. Ping times between server and host average less than 5 ms. I used x11vnc with just the -create -usepw -noxdamage options. I’ve pastebin’d the output at the end of this comment.

1) The only mention of encoding I saw is this (I’ve removed the time stamps):
Pixel format for client 192.168.1.4:
32 bpp, depth 24, little endian
true colour: max r 255 g 255 b 255, shift r 0 g 8 b 16
rfbProcessClientNormalMessage: ignoring unsupported encoding type ultraZip
Using compression level 3 for client 192.168.1.4
Using image quality level 5 for client 192.168.1.4
…
Pixel format for client 192.168.1.4:
32 bpp, depth 24, little endian
true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
no translation needed

Does this help? Is there any other way I can obtain the encoding in use? The viewer I use is krdc. There’s no log viewer there.

If this is something that can be fixed at the viewer, I’d be happy to file a bug for krdc and follow up.

2) The fb read rate is 305 MB/sec.

> BTW, you need to supply the ‘-ncache’ option for ‘-ncache_cr’ to have
any effect.

Oh my! I didn’t know! I’ve been doing it wrong for quite a few weeks, then. Duly noted.

By the way, I’ve filed a wish for krdc to automatically support cropping the view area when using client side pixel caching (https://bugs.kde.org/show_bug.cgi?id=208829).

I’ve pastebin’d the output of the x11vnc server here: (http://pastebin.ca/1589860)

You can use the ‘-rfbport 5900′ option to force it to use 5900 (it will exit if it
cannot open that port.)

Could you characterize the slowness you see? E.g. times for various
activities.

What VNC encoding does x11vnc (or your viewer) report using? If it is
‘RAW’ encoding (sometimes happens for ssh tunnels: the viewer thinks
the server is local) then it will be very slow. Also, what print out at the
beginning for the fb read rate (in MB/sec)?

BTW, you need to supply the ‘-ncache’ option for ‘-ncache_cr’ to have
any effect. However, I recommend answering my questions above
w/o using ncache yet.

$ ssh -p 2222 -L 5959:localhost:5900 localhost x11vnc -create -localhost -usepw -noxdamage -ncache_cr

However, the drawback is that due to the -create flag, x11vnc may open a server on :1 or :2 etc, which means I’d need a tunnel to 5901 or 5902 etc. So, I found that it’s easier to keep the tunneling part separate from the x11vnc part. In practice, I usually open the ssh tunnel first, launch x11vnc and then, open the second tunnel to the port x11vnc ends up using. I’ll edit the above post to make this clear.

Thanks!

However, one can eliminate the ’ssh -fNL 5959…’ if he replaces the last
ssh with:

ssh -p 2222 -L 5959:localhost:5900 localhost

This has the added advantage that the VNC traffic is encrypted end-to-end.

It is also possible (e.g. if you are scripting this) to put the ‘x11vnc …’
at the end of the above ssh. One can also add ‘-localhost’ to the x11vnc
command in this case for a bit more projection.

Also, this blog desperately needs updating. I have three articles in rough draft states that I’ll add here someday I’m bored and have time. I’ll take a look at pdfshuffler soon. Thanks for the heads up!

[Also also, both okular (for KDE4 fans) and evince (for GNOME fans) use the same backend, poppler. So, everything I say about okular should be applicable to evince, too.]