trohling@uceng.UC.EDU (tom rohling) (11/30/89)
After all the recent discussion of video thangs, it reminds me of a problem
that we have yet to resolve. It goes like this:
In order to make things easier (which is a subjective opinion) we had
written our own routine to 'compress' a full 1280x1024 image down to TV size
of (about) 640x484. To do this we used the RECTRE subroutine to read the
colormap info for the whole screen into an array. We then determined what
the RGB values were and went about our averaging to reduce it down to TV
size and then dumped it to a file for transfer to the Abekus A60. All was
fine and dandy until we had the 70GT upgraded to a 120GTX. Now, the results
of RECTRE turn out really(!!) strange (yes, I've recompiled it numerous
times). It seems that it now only reads in about a quarter of the screen
(from 0,0 to about ~600,600 in pixels) and of that which it does read in,
there are random lines where it is missing colormap information. For
example, if I cleared the screen as say green, call RECTRE, then look at the
array that it read the map info into, only the pixels for the lower left
half of the screen show a colormap number of 2, the rest are all zero
(black) with random horizontal lines also containing zero's.
Here's what the program looks like: (I haven't totally learned C yet so
its in fortran)
INTEGER*2 SGIS(0:1310720)
INTEGER*4 TEST
.
.
graphics inits
.
.
TEST=RECTRE(1,1,1274,1022,SGIS)
WRITE(6,*)TEST
WRITE(8,*)SGIS
.
.
averaging stuff
.
.
END
The value of TEST should be the number of pixels that were read by
RECTRE, this also used to work.
This had worked beautifully before the upgrade but now it doesn't. In
the upgrade, the OS release went from 3.1B to 3.1D, with the machine going
from a single processor to a two processor unit. I couldn't imagine a
rather minor OS change affecting things this much, going to two processors
seems like a more probable cause, but anything can happen.
***************************************
HELP!HELP!HELP!HELP!HELP! big projects are approaching their deadlines!!
***************************************
While I'm on the subject of idiosyncrasies, every once and a while,
I have the need to run a few graphics programs in sequential order where I
don't have to do any interacting with them as they run (like averaging
several images from separate programs). So its real handy to put them in a
script and execute them in order (like during lunch). The problem is is
that as soon as the first program initializes the graphics (like opening a
window) the unix prompt is returned. Well, right away the next program
starts to run. But wait! The first program isn't even half way completed
yet. This continues to the point where the cpu('s) are so overloaded that
virtually nothing happens. (By the way, if one processor is
displaying graphics images on the screen, and the other processor tries to
run a graphics program also, you never see its results anywhere. Is the
second one floating in la-la land somewhere or what?) The problem is is
that when the graphics mode kicks in, the system will start to accept input
from std. input. *** Is there a way to prevent this???? i.e. wait until
one graphics program is completely finished until the system returns to
accepting input???
This is more annoying than it is a problem but nonetheless it'd be nice
if it can be fixed.
Any help on any of the above problems from the audience out there would be a
great help.
Tom Rohling
CFD dude
University of Cincinnati
==========================================================================
'No more heros,
No more lights.
No more darkness,
No more fights.'
- deep dark poetry attempt by myself
==========================================================================thant@horus.sgi.com (Thant Tessman) (12/01/89)
In article <2994@uceng.UC.EDU>, trohling@uceng.UC.EDU (tom rohling) writes: [first problem deleted... I try to ignore FORTRAN with the hope that it will go away] > While I'm on the subject of idiosyncrasies, [description of second problem shortened] > The problem is is > that when the graphics mode kicks in, the system will start to accept input > from std. input. *** Is there a way to prevent this???? i.e. wait until > one graphics program is completely finished until the system returns to > accepting input??? Precede your call to winopen with a call to foreground. It makes it do exactly what you want. > > Any help on any of the above problems from the audience out there would be a > great help. > > > Tom Rohling > CFD dude > University of Cincinnati > thant There are 336 dimples on the standard golf ball.
mcqueen@acf4.NYU.EDU (David M. McQueen) (12/04/89)
With regard to your problem when running several graphics programs in sequence: by default, the program runs as a background job after graphics initialization. To prevent this from happening, place a call to foregr (in FORTRAN, or foreground, in C) before calling winopen. This will keep each job in the foreground until completion, when the next job will start up. Dave McQueen Courant Institute of Mathematical Sciences, New York University mcqueen@acf4.nyu.edu