blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (10/02/90)
A while back I posted a request, and since no one from SGI responded, and since I have recieved requests as to if I had gotten any information... Here we go again. The 4Dgifts/imgtools utility scrsave has a call to gl_readscreen. This routine aparently returns the RGB values of pixels on the screen along a constant y line, regardless of mode (i.e. color map, RGB) Why isn't this a "normal" graphics call. For people trying create screen dump utilities this is a key routine. What library is this routine in? Can we expect it to be documented in the future? And DON'T tell me to use scrsave (or icut/snapshot which call scrsave), this is NOT an answere. This is mainly aimed at SGI people. Can any of them answere this? I am not the only one interested in this. -- Brent
" ratcliffe) (10/03/90)
In article <9010021504.AA11064@aero4.larc.nasa.gov> blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") writes: > > A while back I posted a request, and since no one from SGI responded, >and since I have recieved requests as to if I had gotten any information... >Here we go again. > > The 4Dgifts/imgtools utility scrsave has a call to gl_readscreen. >This routine aparently returns the RGB values of pixels on the screen >along a constant y line, regardless of mode (i.e. color map, RGB) >Why isn't this a "normal" graphics call. For people trying create screen >dump utilities this is a key routine. What library is this routine in? >Can we expect it to be documented in the future? And DON'T tell me >to use scrsave (or icut/snapshot which call scrsave), this is NOT an >answere. This is mainly aimed at SGI people. Can any of them answere >this? I am not the only one interested in this. brent- i am an sgi person--*the* sgi person who in fact *did* respond to your query for more info on gl_readscreen back on september 5 (see below). you need to be more methodical in reading ALL messages posted here on comp.sys.sgi, *before* you start ragging about "since no one from SGI responded"... such unfounded indignation doesn't show you off in a good light. to add one clarification to the below: gl_readscreen will ALWAYS return RGB values for whatever pixel locations you tell it to get. it makes no difference if those locations contain RGB or color map or a combination of both. the returned result is always RGB values. i WON'T tell you to use scrsave, but i WILL ask you to tighten up your side of the communication link we have going here. i spent about 45 minutes of my time composing the below response to yer original query to try to help you understand the history of *why* gl_readscreen hasn't been transformed into a support GL function *yet*. please do your part to be on the lookout for such responses in the future *before* you jump up and down and try to imply that sgi isn't listening/concerned about what problems you are encountering with our products. ok? (i've been in support here for 4-plus years. we bust our asses trying to give the best service we possible can to our customers. but this only works IF the customers agree to help us help them.) From odin!dave Wed Sep 5 11:46:35 PDT 1990 Article: 4680 of comp.sys.sgi Newsgroups: comp.sys.sgi Path: odin!dave From: dave@sgi.com (dave "who can do? ratmandu!" ratcliffe) Subject: Re: Saving Screen to file (gl_readscreen will be replaced/isn't docu'd) Message-ID: <1990Sep5.182340.24342@odin.corp.sgi.com> Keywords: scrsave->gl_readscreen->undocumented low-level GL source code function Sender: news@odin.corp.sgi.com (Net News) Organization: Silicon Graphics, Inc., Mountain View, CA References: <9009041916.AA04157@aero4.larc.nasa.gov> Date: Wed, 5 Sep 90 18:23:40 GMT Lines: 102 In article <9009041916.AA04157@aero4.larc.nasa.gov> blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") writes: > > I would like to be able to save the entire screen (or part of it) >to a file of my own format. It shouldn't matter what mode the windows >are in, RGB or color map, I want the RGB values no matter what mode the >window is in. That way if I have a window in RGB mode and one in color >map mode I can save the entire screen as RGB values. > I have looked at 4Dgifts/iristools/imgtools and there is one utility >to save the screen, that is scrsave. Scrsave calls an undocumented >function gl_readscreen. What library is this routine in? ----------------------------> /usr/lib/libgl.a > Why isn't it >documented? THE SHORT ANSWER: ----------------- because this is an evolving subtree of goodies that originally was created as the ultimate freebie with no concern about it's "rigorous supportability". THE LONG ANSWER: ----------------- long ago in a universe far away there was the 2000/3000 machine subtree of /usr/people/gifts/mextools which, once the era of 4D-ness was upon us was ported--a year and a half late--to /usr/people/4Dgifts/iristools. the original gifts/mextools was the "first world" incarnation of an SGI image library courtesy of one of the most inspired populants ever to grace the halls of SGI. with the re-incarnation of 4Dgifts/iristools, the "second world" was given form which was a greatly enhanced and expanded version of the first. however, being an ongoing evolution of functionality there still were "hidden/secret" incantations that hailed from the innards of libgl.a which, by their nature were/are not documented. three of the four of these gl_ GL source code calls have been expunged as of the 3.3 release. the single remaining vagrant is the ubiquituous gl_readscreen. this was not replaced with a standard GL function call as of 3.3 because it's "replacement" is NOT a trivial matter and closure on the remaining ambiguities about its current form and function was not able to be achieved in time. ever since 4Dgifts/iristools made its debut, support engineering has received an ongoing litany of confusion/frustration/concern about this single "jump-door" between the visible universe of the GL Reference Manual, and the invisible, apparently dimensionless universe of libgl.a. as the one who has been responsible for 4Dgifts, i made a concerted effort last fall to achieve closure on this anachronism *before* the development of the [then future] 3.3 release was frozen. unfortunately, i failed in my quest. quoting a segment from one of the many e-mail proposal pieces i sent around the internal circuit late last year: - i have a personal stake in a TIMELY resolution to the issue of replacing gl_readscreen with a supported function that includes, among other things, a concise, well-defined man-page that cust's can refer to for the bottom line of how such a function REALLY works and what they can expect it to do and not to do. Such customer interest has been increasing since 4Dgifts was created and beyond that, with the introduction of snapshot--people want to know more about this ubiquitous gl_readscreen wraith. From a support issue, i have been assuring people for at least six months that i would see to it that gl_readscreen will be soon supplanted with a support function. i don't feel as if this promise was unrealistic. Hence i have become its primary advocate. suffice it to say that we are intimately aware of the aberration. we are engaged in trying to reach a consensus about how to replace gl_readscreen with a supported/fully-documented GL function, but the various issues pertinent to this transmorgrification are still being debated in terms of how this call is related to other functionality still needing clarification. > It seems to be the only function that will do what I want, >however there is no documentation. Is it ok to use this function or will >it disappear some day. it *will* disappear someday > It should be a normal library function, complete >with documentation. > I have tried using other routines with no success. Any suggestions? >Most of this is aimed at SGI. as you have already surmised, no other function provides the kind of i-can- grab-any-section-of-the-screen-you-want-regardless-of-it's-window's-display- mode,-and-return-to-you-an-RGB-SGI-imagelib-image-file. the gl_readscreen function implementation varies based on which machine yer on. in the GT[X] version it is approximately 85 lines and comprises about 5 different gl_ calls within its body. it does ALOT of low-level ugly-gutsy stuff that provides you with the i-don't-care what-displaymode-yer-running capability. there really is nothing you can do to "replace" gl_readscreen until we are successful in doing so in-house and then incorporating it into the next SW release. in the meantime, the best (and i'll grant you its not good enuff) thing i can suggest is to know that gl_readscreen only can work on one scanline at a time--it's maximum length being XMAXSCREEN--and that the addresses of the three arrays you pass in will come back with the red, green, and blue components of each pixel on that scanline starting at the X position you set things to via cmov2i prior to calling gl_readscreen. sorry for the hassles. this stuff has not solidified yet. -- daveus rattus yer friendly neighborhood ratman KOYAANISQATSI ko.yan.nis.qatsi (from the Hopi Language) n. 1. crazy life. 2. life in turmoil. 3. life out of balance. 4. life disintegrating. 5. a state of life that calls for another way of living.
jim@baroque.Stanford.EDU (James Helman) (10/05/90)
I can almost hear it now, someone saying: "See what happens when we give out source code? Users snoop around and then start complaining about undocumented features. Enough! No more." No doubt, SGI gets some hassles this way, but I hope it won't reduce the amount source code SGI releases. Personally, I appreciate what's there and would like to see more. One good program is worth a dozen great manuals. Jim Helman Department of Applied Physics Durand 012 Stanford University FAX: (415) 725-3377 (jim@KAOS.stanford.edu) Work: (415) 723-9127
amen@SGI.COM (Bob Amen) (10/06/90)
From article <9010021504.AA11064@aero4.larc.nasa.gov>, by blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854"):
+
+ The 4Dgifts/imgtools utility scrsave has a call to gl_readscreen.
+ Why isn't this a "normal" graphics call.
Routines beginning in gl_ are routines internal to the GL and are
not guaranteed to be there at all in the next release. If they are in future
releases fo the GL they are not guaranteed to have the same calling arguments,
etc.
+ For people trying create screen dump utilities this is a key routine.
Look at lrectread(3g), readsource(3g), pixmode(3g) and readRGB(3g).
+ And DON'T tell me to use scrsave (or icut/snapshot which call scrsave).
Ok, I won't.
+ --
+
+ Brent
--
Bob Amen (amen@sgi.com) (+1 213 312-0227)
Silicon Graphics Computer Systems -- Los Angeles Office