What encoding are you using? What speed network are you on? If you are using RAW encoding, you might try going to hextile. You could also try Tight avaliable with TightVNC, but if you are on a high speed network, this might actually make things worse.
If the backgroud is dithered, I know Tight is supposed to have some dithering alogorithims to help with dithered window titlebars and such, but I am not sure of the exact parapaters of the function and if it would work on a dithered background. More then likely it would send the highlight over JPEG encoded or RAW depending if you enabled the JPEG opiton. Either way, it would be just as slow as VNC or slower I would think. Might be worth a try. This is a good reason I would really like to know more information about how the pluggable encoders are going to work with VNC 4/5. This situation could really take advantage of a seperate encoder for hextile/tight style data and raw/jpeg style data. For lack of better wording, vector data and bitmap data. I know this might complicate the already hard process of picking an encoding, but I can see is being usefull a lot. For example, on a loaded 10mbit network, I would think hextile with JPEG support would work best. On Tue, 2001-10-30 at 17:55, Russ Ferriday wrote: > I would appreciate any suggestions regarding a performance problem I'm > having. > > Background: > We develop Java apps using Together/J and NetBeans running on a dual > Pentium 1GHz with 1GB RAM, with Linux 7.1. We have vnc 3.3.3r2 and start > the server like this... > vncserver -cc3 -geometry 1600x1200 > Classic VNC setup, just switched to KDE as window manager. Very happy in > general. > > Reference point: > Under KDE or FVWM2 on the console Together/J and Netbeans work fine. > Fast response, no problems. > > Problem under VNC: > Together/J runs pretty poorly when editing code, selecting text with a > double click, etc. > However Netbeans runs fine - very fast. > > Easy to see why once you fire up Ethereal... > There is vastly more network traffic with Together/J than with Netbeans > on similar work. Highlight a word and Together/J updates a whole text > control sending 1.3MB of data to the viewer, where Netbeans sends less > than 100KB. > > Short of rewriting Together/J, and all the performance suggestions in > the FAQ, are there any options for working around the problem? It seems > that the update to the large text control causes masses of redundant > data to traverse the network, when actually only the highlighting on a > word has changed. This is counterintiuitive to me, and I would not have > expected only pure framebuffer changes to be relayed. Another piece of > information, it seems that the text background ends up with some > dithering on it that we are unable to eliminate. This would explain why > the encoded area takes up 1.3MB. > > Thoughts? > > -- > =========================================================== > Russ Ferriday (805) 543-4895 x206 > Chief Technical Officer > Focus Learning Corporation > San Luis Obispo, CA > --------------------------------------------------------------------- > To unsubscribe, mail [EMAIL PROTECTED] with the line: > 'unsubscribe vnc-list' in the message BODY > See also: http://www.uk.research.att.com/vnc/intouch.html > --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
