Path: utzoo!utgpu!news-server.csri.toronto.edu!eecg.toronto.edu!drb Newsgroups: comp.sys.sgi From: drb@eecg.toronto.edu (David R. Blythe) Subject: Re: SGI's migration to X Message-ID: <1990Sep11.234709.27405@jarvis.csri.toronto.edu> Organization: EECG, University of Toronto References: <208@voodoo.UUCP> <1990Sep6.010419.1573@odin.corp.sgi.com> <1990Sep6.175301.18898@jarvis.csri.toronto.edu> <1990Sep7.190102.28444@odin.corp.sgi.com> Date: 12 Sep 90 03:47:09 GMT Lines: 24 In article <1990Sep7.190102.28444@odin.corp.sgi.com> msc@sgi.com writes: >0747@baroque.Stanford.EDU> <1990Sep6.010419.1573@odin.corp.sgi.com> <1990Sep6.175301.18898@jarvis.csri.toronto.edu> > >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. Okay I misunderstood, despite your great pains. Rather than ask for more details, I just stated the problem I wanted solved. > >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. I think this is a little contentious, the X protocol design shouldn't preclude doing fast graphics or having a fast path to the graphics hardware. I hope the goal and end result of the X protocol isn't low bandwidth graphics but rather just a temporary implementation difficulty. I'll certainly agree trying to retrofit X into GL is a pain, but the fewer hitches there are to using the combined interface (from performance, ease of use, and generality points of view) the better off we will all be. -drb