One alternative suggestion - if X windows works well, you could try the
port of XFree86 to Win32 DirectX that was done with CygWin. This is
developer code, and I haven't tested it, so I will simply leave you with
the link and let you check it out for yourself. In theory, as an X server
sitting on DirectDraw, it should be able to use any available hardware
acceleration (fast lines, circles, blits, etc).
http://sources.redhat.com/cygwin/xfree/
As for VNC, I can't help much. Sounds like either VNC has amazingly bad
PseudoColor support (possible, since AT&T doesn't seem to use it) or Apollo
is doing something incredibly stupid that is forcing Xvnc to push a lot of
data to the client. I have seen CAD programs that did lots of screen
blanking, which can be done on local hardware within one screen refresh
(even on a remote X Terminal, the command only takes one packet to
transmit, and then the remote hardware could do the blank very quickly).
VNC, on the other hand, must transmit the entire blank screen and apply
that. With hextile encoding, this operation should be very fast, but other
encodings would have trouble. (Question for Developers: does hextile
understand PseudoColor? If not, it will fall back to something like Raw,
which will be PAINFULLY slow for this kind of operation)
Also, are you doing any kind of secure tunnelling that involves machines
connecting to a port on localhost that is then forwarded? If so, make sure
that the client and server are not agreeing to use RAW encoding. I'm not
sure exactly which situations lead to this, but I know that sometimes I get
a report "Connecting to same machine : preferring Raw encoding" (or
something very similar - I don't have the message in front of me right
now). I discovered this while trying to tunnel (with program of my own
design) over a link that did not have PPP support. The transmission was
painfully slow, because it thought that the server and client were on the
same machine, so it switched to Raw encoding, which would be very slow for
full screen blanking.
Is there any way that you could establish a protected minimalist account on
a machine so that developers could run VNC clients against your Apollo
program and see what was happening? This may not be possible from
licensing, security, or bandwidth usage concerns, but it would be extremely
helpful for the people who understand the underlying code to figure out why
Apollo is having so much trouble. (Question for Developers: if Jeff can
actually get clearance to do this, would you be willing to investigate the
matter, in the interest of a better, more capable Xvnc?)
You could also check out http://www.tridiavnc.com, who have made several
modifications to VNC. I have no idea if they have made any fundamental
changes to the PseudoColor support.
Mac (just another user, with occasional forays into development)
---------------------------------------------------------------------
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
---------------------------------------------------------------------
