Bruce Anderson wrote: > > look in the connection log on the server and see what encoding > the PC uses. > > A couple of observations: > 1) VNC server is based on old X11 code base. > 2) server does all rendering in user space mem > on the server, where as in the case of X the > server runs on the client and has access to > video cards hardware accel. > 3) See the mailing list archive for: > Subject: "VNCViewer slow on Win32 vs Linux"
Hi, Bruce, I tried all encodings: tight, hextile raw, RRE; all with copyrect, and switching the 8-bit-per-pixel on/off. Compared to, tightVNC, realVNC's automated parameter selection won't help much since the channel doesn't vary. I think there are 2 levels of slowdown happening here. On the sun boxes, if both the VNC server and viewer are 8-bit pseudocolor, there is no detectable delay. If there is translation, there is slight delay. For example, I described launching a 24-bit true color server in which I launch a viewer to connect to the 8-bit pseudocolor server on which the CAD tool is running. This results in tight encoding with compresslevel of 1 (though the compress level doesn't seem to matter much). Note that there are actually two VNC links here, since I have to connect to the 24-bit true color server from an actual Xsession on the same machine. The loopback connection's encoding doesn't matter much either (raw, hextile, tight of various levels). So the end result is that translation and dual VNC links causes a small bit of slowdown, and the encoding doesn't matter much. So long as a PC is not involved. The use of a PC for the viewer causes significantly more slowdown, regardless of encoding and whether 8-bit-per-pixel is activated. I noticed that the thread you alluded to mentioned the encoding as the possible cause. However, these are the same encodings that did not cause a problem with the sun-to-sun connections. I confirmed this by examining the server log file in all cases. So the cause must be either a bottleneck between PC and sun networks; or, as implied by you above (and in the thread), that the PC-based viewer is not written to exploit the PC's graphic rendering capabilities very well. For the case of narrow bandwidth, Exceed might not be has hard hit by the narrow bandwidth if it does make good use of PC rendering abilities, and if the CAD app makes use of high level X windows commands. I'm not familiar enough with X to know the extent to which this can be done, if it is in fact happening. But I do observe that Exceed is not as badly slowed down as VNC for the CAD app. The thread didn't mention which app, but mine's is Cadence. In addition to the possible causes above, the fast flicking cursor I mentioned previously hints at the possibility that there is excessive polling or communication of some sort between the app and the X server which might be slowing down VNC. Just a (possibly naive) guess from a nongraphics guy. But it does corroborate with other experiences. It is only the IC layout package that is hit so hard by slowness. Other CAD packages are slowed, but still usable. For example, schematic capture is usable, as is Synopsys synthesis. Someone mentioned that their CAD package inefficiently changes the colormap once a second to make the cursor blink. It may or may not be related, but I think the slowdown I'm seeing must be due to something more severe than an event that happens once a second I should add that VNC is preferable for everything else but CAD. This is because Exceed has this very annoying delay in starting up new windows. I can only guess why. Maybe it's doing a whole lot of X book keeping as retribution for using high- level commands. Maybe it's using some kind of buffering scheme to paint a new frame. As I mentioned previously, it seems to switch between two drastically different images very fast. Also, using Exceed, you run the risk of killing all your work if the viewer dies. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
