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: <1990Sep6.175301.18898@jarvis.csri.toronto.edu> Organization: EECG, University of Toronto References: <208@voodoo.UUCP> <1990Sep6.010419.1573@odin.corp.sgi.com> Date: 6 Sep 90 21:53:01 GMT Lines: 28 In article <1990Sep6.010419.1573@odin.corp.sgi.com> msc@sgi.com writes: > >Even if it's possible, we don't recommend doing it. Trying to image into >the same window using both X and the GL raises a bunch of nasty issues of >which one of the nastiest is synchronizing the drawing. Has the GL finished >drawing this polygon so I can have X draw this line? Who's on first so to >speak. Ugh!! > 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. 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. drb@clsc.utoronto.ca >-- >From the TARDIS of Mark Callow >msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc