multi-processes and GL windows

Micah Altman micah at martika.csd.sgi.com
Thu Jun 20 22:33:18 AEST 1991


In <1991Jun19.211639.22548 at uceng.UC.EDU> trohling at uceng.UC.EDU (tom rohling) writes:


>       Is it possible to have multiple processes render to the same
>    graphics window?

Yes. Use sproc(...,PR_SALL,...) . Do this _after_ you've done your
first winopen() call ( winopen() causes a fork() if not foregrounded,
which causes processes previously created to lose track of the windows ).

However, this is usually not advisable.

You'll need to synchronize, to make sure that the pipe is not addressed 
simultaneously. Each process will need to complete its bgn* end* group
before the other process can access graphics legally.
Furthermore, there is a lot of "state" associated with
the graphics engine, and if you change state (current color, viewing matrix,
etc, etc, ) with one process it will affect other.


>       The possible scenario would be something like this:

>       I start up a main process to do some rendering which controls
>    what rendering to do.  Each of the available rendering routines will
>    be a separate process (executable).  That way, I can add new routines
>    without having to recompile the main every time.  Anyway, each of

Can't see what this has to do with recompiling. You should be able
to minimize your recompiling by modularizing your code and breaking
it up into files, parallel processing shouldn't effect this.

>    the individual rendering processes should be able to render to the
>    same window in sequential order, one after the other, that way there
>    is no conflict in sending things down the graphics pipe.  

Probably a more efficient thing to do is to have one rendering process,
and if you have cpu cycles to burn --- multiple computation and/or culling
processes.
--
	"Entia non sunt multiplicanda sine necessitate." - William of Ockham
	Micah Altman, "Computational Juggler"	   	   micah at csd.sgi.com
	Phone (415) 335-1866				   FAX (415) 965-2309
	Disclaimer: 	Everything in this document is a lie.	



More information about the Comp.sys.sgi mailing list