Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!decwrl!sgi!shinobu!odin!ramoth.esd.sgi.com!msc From: msc@ramoth.esd.sgi.com (Mark Callow) Newsgroups: comp.sys.sgi Subject: Re: SGI's migration to X Message-ID: <1990Sep7.190102.28444@odin.corp.sgi.com> Date: 7 Sep 90 19:01:02 GMT References: <208@voodoo.UUCP> <1990Sep6.010419.1573@odin.corp.sgi.com> <1990Sep6.175301.18898@jarvis.csri.toronto.edu> Sender: news@odin.corp.sgi.com (Net News) Reply-To: msc@sgi.com Organization: Silicon Graphics Inc., Entry Systems Division Lines: 38 In article <1990Sep6.175301.18898@jarvis.csri.toronto.edu>, drb@eecg.toronto.edu (David R. Blythe) writes: |> It would be really really really really nice if whatever X toolkit/UIMS/etc |> gets fobbed off on me (i.e. Motif,OpenLook) also works with GL graphics. |> That is to say, I want to learn *one* subroutine library for popups, |> pulldowns, radio knobs, other crap that can be used in both a GL window and an |> X window. This would seem like a good reason to have X requests and GL |> requests work together, rather than making a GL version of the same library. Apparently you didn't read the last paragraph of my message where I pointed out that you will be able to to mix GL and X subwindows within a single top-level window. This is all the support you need to use any of the X toolkits. |> If a client is local can't it use the same direct paths to the hardware as GL |> (i.e. have X built on top of or in conjunction with GL (either through the |> X server, or bypassing it when possible) rather than a separate |> entity)? Remote requests would have to go through a serializer, so the remote |> guy may pay some performance penalty in extra overhead but it seems worth it |> to keep the local stuff fast and integrated. It can be done but remember we are talking about a fast path to the graphics hardware which is a very different thing than the X server. Xlib has to be extensively rewritten, a fairly massive undertaking that is difficult to do without breaking fundamental things about X. IBM has done it. Unfortunately their system decides which version of Xlib to use (the standard one or the rewritten one) based on whether the first display the client opens is local or remote. If a client opens a local display then a remote display ... oops. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."