Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!unmvax!tut.cis.ohio-state.edu!ucbvax!BRL.MIL!mike
From: mike@BRL.MIL (Mike Muuss)
Newsgroups: comp.sys.sgi
Subject: lrectwrite & gsync?
Message-ID: <8903030550.aa06677@SPARK.BRL.MIL>
Date: 3 Mar 89 10:50:11 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 35

My thanks to the folks from SGI who informed me that ps_open_PostScript()
not being machine independent presently, and that the new release fixes
this.

Since I am forced to abandon the portability topic until we get the
fabled next release, I have moved on to some performance enhancements.

I have noticed that if I write the entire screen (on a GT) with
a single call to lrectwrite(), it proceeds with blinding speed.
If, however, I send the same amount of data using one call to
lrectwrite() per scanline, it proceeds at the rate of about 1000
scalines/second, which is very slow.

Running gr_osview during this time, I notice that total user time
is about 3%, and system time averages 40-60% !!!  I am calling
lrectwrite() in a loop, there are no (intentional) system calls
being made.  What I suspect is that lrectwrite() may be doing
something like a gsync() on every call, or perhaps notifying
the window manager that this might be a good time for another process
to have a chance to do some graphics, or some such.

I seek a way to stop this behavior.  Can anybody help?

(I find nothing about this in the online manuals.  I know from writing
SunView programs that acquiring a "window manager lock" is something
that some systems permit.  Is there a comparable SGI routine that
will do as I wish?)

Suggestions to reformat the in-memory data into a form so that I can
ALWAYS use a single lrectwrite() are not helpful. Sometimes I can do
it all in one, sometimes not.  It would cost 4 Mbytes of extra memory
and a lot of data copies to shuffle things.

	Thanks,
	 -Mike