> 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.
* Run the viewer using its own colormap. This can be done with the X VNC
viewer on a PseudoColor display with the -owncmap option, but I don't think
it can be done with the Windows viewer as is. It might be possible to modify
the Windows viewer to tell the VNC server that it uses a colormap and then do
the translation itself (in fact I suspect the Windows API might even do the
translation for you). Not being a Windows programmer I don't know how hard
this would be.
* Ideally Xvnc could be made "smarter" about working out how much of the screen
is affected by a colormap change, but that's really quite hard (you'd need a
kind of "reverse index" of the framebuffer, telling you for each pixel value
whether that pixel value occurs in particular areas of the screen).
Hope this helps,
Cheers
Tristan
---------------------------------------------------------------------------
Tristan Richardson [EMAIL PROTECTED] www.uk.research.att.com/~tjr
---------------------------------------------------------------------------
AT&T Laboratories Cambridge, 24a Trumpington Street, Cambridge, CB2 1QA, UK
Tel: +44 1223 343000 Fax: +44 1223 313542 www.uk.research.att.com
---------------------------------------------------------------------------
---------------------------------------------------------------------
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
---------------------------------------------------------------------
