RE: Java port to VSTa? -- tangent

If you're looking for a network transparent windowing environment with
incredible 2-D capabilities you should check out
Berlin(http://www.berlin-consortium.org) It's a new vector based window
system developed from scratch and built on CORBA and
GGI(http://www.ggi-project.org). GGI also forms the base graphics library
for the 3-D window manager project(http://www.3dwm.org). Berlin is currently
being developed in C++. I believe they also have plans to integrate other
media into the transport model so they can network transparent audio and
video, but I'm not sure. You'd have to check out the mailing lists.

These look like a great starting point. Were they to suit the exact needs
the remainder of my work would be cranking up the frame rate end-to end from
the server to its display on /n/ subscribing clients. CORBA makes a
convenient connection aide but imposes marshalling overhead if used
religiously. I would be content to write dedicated protocols thereafter for
packet and streaming updates of the right fit.
I'm certain all of the pieces exist for a really spiffy 3d remote terminal
environment, but all these pieces have been built with different purpose in
mind. My ideal concept of a remote client update is like follows:
Machines A,B;
Process Exists on A
Process Display Context on B
B has n [{X11|Glide|opengl|directx|ggi?}] displays, and could be a repeater
to C.
a) A or B is capable of delivering raw image data to displays; where A could
(in an ideal world) dump translated machine-specific buffers across the
network to waiting DMA on the AGP bus.
b) A could also encode/encrypt/compress image data for reciprocal decoding
on B.
on a fast network where A is a beefy server and B is an underpowered
graphics workstation, the choice to send raw machine specific info rendered
on the server would yield a snappier frame rate. Exactly what the bandwidth
could bear. Unknown if this approach scales for 3d info, but one could a
take a lesson from the Quake engine on remote 3d rendering. Bandwidth is
king.
VNC sends bitmap corrections through an encoding pipe, X11 sends X11
primitives across the wire. VNC is a huge drain on CPU on both client and
server, due to its bandwidth-saving encoders. On a 200mhz Pentium it's a
noticeable drag serving remote display as well.
X11 is a joy to work with but is specific to X11 overhead, and can sometimes
thrash bandwidth needlessly with trivial updates made.
There is no middle ground, nor are VNC or X11 multimedia savvy protocols;
but the chipsets exist for these features, and machines with these chipsets
will retire as certain as Moore's Law marches on.
It's such a performance hungry bent that I'm on that makes it so attractive
to consider VSTA as a choice as good as any more established platform.
These concepts would be easily expressed in kernel level services, more so
than building an application architecture around the problem. It would
probably put my entire perspective into sharper focus to need to port Glide
to VSTA, port Xvfb, port GGI, etc. It's problem I am looking forward to
having :)

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Received on Tue Feb 13 11:24:31 2001