I'll try to explain what is causing our viewer to be a bit slower than a native one.
Comparing with RealVNC viewers (especially with a RealVNC v4.0). In RealVNC v4.0 the developers did a good job and rewritten a rendering code. And if you compare RealVNC v4 viewer speed with pre-v4 versions or with TightVNC/UltraVNC viewers you will notice that RealVNC viewer is faster (this is especially noticable on a large screens. We had a customer who had 10000x2000 pixels screen and TightVNC viewer was way slower on such screen).
So the first reason for slowes is a fact that our viewer is based on TightVNC 1.3dev6 code base, which is slower than RealVNC v4 viewer.
Another reason, which is a bit mystery for us, is that when you place an ActiveX control inside .Net based application, it starts to work a bit slower. I guess due to additional layer of proxy code generated by .Net runtime.
Ok. Now what we are going to do about it. At the moment we are considering two possible solutions:
1) TightVNC has plans to port their viewer to RealVNC code base and hence increase rendering speed. As soon as they port their viewer, we are going to port our ViewerX on a new code base, which should take more than a week. The problem is that TightVNC is very slow with releasing new version and it's unclear when they release a new build.
2) So another idea just to port our ViewerX to RealVNC code base. We actually already have such version, which we created for the customer with 10000x2000 screen problem. It just needs some polishing and bug fixing.
We are not going to update Viewer control in v3.0 release. But that's what we will be doing right after the release. So I guess VNC Manager v3.0.X will include a new Viewer control. You just have to wait a couple more months till it happens.