SGI's migration to X

Mark Callow msc at ramoth.esd.sgi.com
Thu Sep 6 11:04:19 AEST 1990


In article <JIM.90Sep5130747 at baroque.Stanford.EDU>, jim at baroque.Stanford.EDU
(James Helman) writes:
|> Once SGI's current window coexistence problems are fixed, will SGI's
|> GL/X dichotomy be pretty much the same as Sun's XGL/X split?  That is
|> once a window is opened either as a local X window or as a "direct"
|> graphics window, there is no way to get a handle for applying the
|> other's drawing calls on that window?

After t-day (or should that be X-day) a program will be able to make windows
using either X calls (referred to as an X client) or the existing GL calls
(referred to as a GL client).  GL clients will draw in the window
using the GL just as they do today.  GL clients can obtain the X window id
of the window if desired.

An X client may use new GL calls to initialize the GL, obtain a GL
rendering context and bind that context to the X window of their
choice.  They then render into that window using the usual GL calls.
I'm not sure if the X client will also be able to render using X
calls.  One of our server gods can answer more authoritatively than I.

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!!

In case anybody misunderstands what I mean by the "same window" let me
explain.  You will be able to make a top level X window with several
subwindows.  You may image into one of more of the subwindows using the GL
and into the remaining subwindows using X.  What we do not recommend is
trying to render into the same subwindow using both GL and X.
--
>From the TARDIS of Mark Callow
msc at 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."



More information about the Comp.sys.sgi mailing list