fineman@ptolemy-ri.arc.nasa.gov (Charles Fineman) (06/27/91)
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 Finemanjordan@tcs.COM (Jordan Hayes) (06/27/91)
Chuck Fineman <fineman@ptolemy-ri.arc.nasa.gov> asks: 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???). Nope. You can have multiple displays in a single AppContext. /jordan
klee@wsl.dec.com (Ken Lee) (06/27/91)
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???). If you're using the X Toolkit, just put all the displays in the same application context and call XtAppMainLoop. The X Toolkit automatically handles all the different displays properly. If you're not using the X Toolkit (why aren't you?), you have to use operating system dependent techniques for blocking on multiple connections. In systems derived from BSD UNIX, the ConnectionNumber() macro will give you the socket descriptor. You can pass these to select(), which will block on all the connections until one is ready for reading. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
fineman@popper.NoSubdomain.NoDomain (Charles Fineman) (06/27/91)
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
will@rins.ryukoku.ac.jp (will) (06/27/91)
Chuck Fineman, can you please send me your email address, my mailer does not show a proper address for you. Will...
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (06/28/91)
[ about a program interacting with multiple displays ]
> What about the case when the toolkit is not being used?
There is no simple solution. You have to depend on Xlib internals to
some extent. For example, on Berkeleyish systems, you can generally
use select() to check the relevant file descriptors. The Xlib
internals knowledge comes into play when you realize that you have to
get these file descriptors from somewhere; you use XConnectionNumber
for this.
More generally, XConnectionNumber (or the ConnectionNumber macro)
returns "a connection number for the specified display", to quote the
Xlib document. It also says that "On a POSIX system, this is the file
descriptor of the connection.", so the above is probably a reasonably
safe thing to do, if you're willing to stick to UNIXish systems.
(What about connections that don't have file descriptors? Does the
above forbid such things? I don't know, but wouldn't mind finding out.)
der Mouse
old: mcgill-vision!mouse
new: mouse@larry.mcrcim.mcgill.edujg@crl.dec.com (Jim Gettys) (06/28/91)
In article <1991Jun28.131900.28715@thunder.mcrcim.mcgill.edu>, mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: > More generally, XConnectionNumber (or the ConnectionNumber macro) > returns "a connection number for the specified display", to quote the > Xlib document. It also says that "On a POSIX system, this is the file > descriptor of the connection.", so the above is probably a reasonably > safe thing to do, if you're willing to stick to UNIXish systems. > > (What about connections that don't have file descriptors? Does the > above forbid such things? I don't know, but wouldn't mind finding out.) It doesn't forbid returning other useful information on other than Unix environments; the specification is deliberately silent to allow for such use. - Jim
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (06/29/91)
In article <1991Jun28.132932.21795@crl.dec.com>, jg@crl.dec.com (Jim Gettys) writes: > In article <1991Jun28.131900.28715@thunder.mcrcim.mcgill.edu>, mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: >> [The Xlib document] says that "On a POSIX system, this >> [XConnectionNumber] is the file descriptor of the connection.", >> (What about connections that don't have file descriptors? Does the >> above forbid such things? I don't know, but wouldn't mind finding >> out.) > It doesn't forbid returning other useful information on other than > Unix environments; the specification is deliberately silent to allow > for such use. I didn't say "other than Unix"; I said "don't have file descriptors". There are plenty of ways the connection could be implemented on UNIX that don't involve file descriptors, and some of them are plausible - for example, buffers in a shared memory segment, with semaphores used to tell the other end to look at the buffer. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu