Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!stanford.edu!ptolemy-ri!popper!fineman
From: fineman@popper.NoSubdomain.NoDomain (Charles Fineman)
Newsgroups: comp.windows.x
Subject: Re: How do *you* handle multiple displays?
Message-ID: <14258@ptolemy-ri.arc.nasa.gov>
Date: 26 Jun 91 20:38:17 GMT
References: <14246@maslow.ptolemy-ri.arc.nasa.gov>
Sender: usenet@ptolemy-ri.arc.nasa.gov
Lines: 31

In article <14246@maslow.ptolemy-ri.arc.nasa.gov>, fineman@ptolemy-ri.arc.nasa.gov (Charles Fineman) writes:
|> 
|> I'm working on a performance visualization package and I would like to
|> give the user the option of displaying views on multiple screens. The
|> problem comes when trying to wait for events from the different
|> windows. If the windows are handled by different display servers, the
|> event wait loop turns into a spin-loop since there is no way to do a
|> blocking request for events from multiple servers (right???).
|> 
|> The only other solution I could see is to "fool" a display server into
|> believing that another, remote, display, is really just another screen
|> of this display. Has anyone toyed with this idea before? Would such an
|> extension fit into the exiting generic display server code elegantly?
|> 
|> Has anyone else come up with an interesting (and efficient) solution
|> to this problem?
|> 
|>         Chuck Fineman

I've gotten a couple of responses refering to toolkit functions. First,
how do the toolkit functions handle multiple displays? Do they spin-loop,
checking each display (in a non-blocking mode) each time through, or has
it been integrated into the X library so well that it can use a more 
intelligent method (i.e. select on a set of sockets)?

What about the case when the toolkit is not being used? Please, constructive
comments only! ;-)

	Thanks,

		Chuck Fineman