I having been using VNC with some success for quite a while, but have a
problem with one application that manipulates the colour map in order to
cause parts of the screen to blink.
Xvnc is running on a variety of Unix platforms, and the clients are
typically using the Java client or the windows vncviewer.
If I run Xvnc with the default colour class, blinking does not work at all,
and on Solaris systems the vnc log file fills up with BadAccess errors. If
I run Xvnc with '-cc 3' (PseudoColour), then blinking does work, but it
causes a full screen update because the client is 8bit TrueColour (this is
in rfbSetClientColourMap in translate.c). This causes a noticeable flicker
in the display and significant network load, as the application is changing
the colour map about 3 times a second. If I run the unix vncviewer with its
own colour map, then it all works swimmingly, but that doesn't work for the
users.
Is there any way to do a more intelligent updating of the screen when the
colour map is changed? This particular application is usually only changing
a few rectangles in the screen, so updating the full screen is a huge amount
of overhead. Is there any easy way to walk through the screen pixels,
marking which ones are affected by the colour map change, and generating
updates from that? I'm assuming that changing the windows and Java clients
to support colour maps would be too difficult.
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
