First off, sorry for the accidental previous message.
Tristan ... thanks for the suggested workarounds with modifying the
translate.c file. They appear to have resolved the issues we have seen.
- 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.
>
>* 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
>---------------------------------------------------------------------
>
--
Jeff Boerio, DPG-OR Engineering Computing, [EMAIL PROTECTED]
Mgr, UNIX Software Applications & Support
Desk: (503) 712-217
Mobile: (503) 887-0113
---------------------------------------------------------------------
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
---------------------------------------------------------------------
