Belinda,
Here's a technical explanation of the problem, and the solution.
- Jeff
>> So, when VNC is started using -cc 3, when Apollo is started, the
>> performance goes to pot. The VNC viewer cursor gets WELL ahead of the X
>> cursor.
>>
>> When I quit from Apollo, the performance gets better.
>>
>
>I suspect I know what the problem is.
>
>Going from 8-bit PseudoColor server to a TrueColor viewer is hard to do
>efficiently, because every time the colormap is changed, potentially the whole
>screen is affected. Xvnc "copes" with this by simply sending a complete update
>to the viewer. This works OK for most applications which simply allocate a few
>colours once off, but not for an application like this Apollo which actually
>changes the colormap constantly while it is running.
>
>There are a few things I can suggest (other than finding a version of Apollo
>which doesn't need a PseudoColor server), but they all involve modifying VNC:
>
>* If you're lucky, then this Apollo program won't really be changing pixel
> values which are on the screen, in which case Xvnc sending a full update is
> unnecessary. You can try hacking this bit of Xvnc out by removing lines 399
> to 403 of Xvnc/programs/Xserver/hw/vnc/translate.c:
>
> REGION_UNINIT(pScreen,&cl->modifiedRegion);
> box.x1 = box.y1 = 0;
> box.x2 = rfbScreen.width;
> box.y2 = rfbScreen.height;
> REGION_INIT(pScreen,&cl->modifiedRegion,&box,0);
>
> and recompiling. Even if it doesn't work fully, the worst that should happen
> is some wrong colours on the viewer. It should certainly stop the real
> performance problem.
---------------------------------------------------------------------
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
---------------------------------------------------------------------
