re: Servers vs. Libs

From: James Northrup <james_northrup_at_nospam.org>
Date: Wed Feb 14 2001 - 19:28:51 PST

A former coworker of mine had a gig displaying 3d models rendered on a cray.
As the story goes the cray rendered faster than they could process it.

-----Original Message-----
From: Sandro Magi [mailto:naasking@hotmail.com]
Sent: Tuesday, February 13, 2001 7:29 PM
To: vsta@zendo.com
Subject: Re: Servers vs. Libs

> >Personally I think things that can be put in servers should be put in
> >servers. The graphics is a good example, In plan9 it is in a server
> >providing a device to write to. The programs don't need to be aware at
>all
> >of which graphics hardware there is in the computer.
> >But if it is put in a library instead, it can't be multiplexed (ala 8.5
> >and rio). But probably worse, you would have to code wrappers for the
> >graphics library to each programming language you'd want to code graphics
> >in.
> >And for those that preffer coding graphics by calling functions instead
>of
> >writing data to a device, a library for drawing that uses the
> >device(server) could be coded.
>
>Except that almost every "serious" graphics program does the inevitable
>genesis to the point where it wants memory mapped access to the frame
>buffer. And I'm not really arguing much, since the MGR port could call the
>main mgr process the "graphics server", and then all clients are in their
>own address spaces. But, then, MGR is linked with svgalib to actually
>control the graphics card, so that's adopting the other rule.
>
>The other big question is state management. Multiplexing is one (thus, mgr
>has its own process). But even in a single client case, the complexity of
>state and requirements for cleanup (i.e., on a segv hardware needs to be
>un-programmed) might argue for a distinct process.
>
>Any rule can be applied in such a way that it doesn't make sense. I don't
>see any problem with your arguments.

If graphics were in server, would that enable network transparent graphics?
Since the graphics server would be replying to messages on it's port, it
doesn't matter where those messages are coming from. Couldn't those messages
simply be sent to a graphics server across a network instead of locally?
Would that require much extra effort/coding, or would it happen
automatically? Am I off base? Some serious security issues also come to
mind.

With more thought, the whole distributed graphics server idea seems dubious.
What would be the point of allowing access to your graphics hardware to
another computer on the network? This is a driver issue right? (I was
thinking on a higher level ala X-Windows)

But it brings another question to mind. Is VSTa distributable in this
manner(or is it already)? Can I mount a dos filesystem on another computer
across the network on my own computer?

I'm sure it can be done because of the flexibility of message passing, I'm
just curious if VSTa is currently capable of it. Also, is there some place I
could go for more info on the VSTa design(other than the source code)?
Specifically, a somewhat high level overview of how things currently fit
together.

Thanks for your patience. ;-)

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Received on Wed Feb 14 19:11:48 2001

This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:57 PDT