Why is screendump so touchy

[Howard C. Hart]

And the fun's just starting... I've been using dumpregion.c posted on the
Sun-spots archives which uses the fullscreen() and pr_load() utilities to
dump screen images of user specified width and heights to a file. The two
things I've noticed are: 

	(1)  pr_load() works on color Sun 3/60's for all sizes up to a dump
	of the full screen, but if the mouse is moved across the area to 
	be dumped while its dumping, the image of the mouse appears on the 
	saved image. 

	(2)  pr_load() only works occasionally on a color 3/260. If the 
	image to be saved gets over a certain size (about a third of the
	full screen), patches of black or striations appear on the saved
	image, along with good portions of the saved image. The same effect
	occurs using screendump.

In the case of the 3/60, you'd expect pr_load() to freeze the frame prior
to dumping, grabbing the mouse image also if it happened to be in the
frame area.  The 3/260 is, however, a real mystery. I know it's not a
memory problem, since there's 16 MB of RAM. I also know a screen can be
dumped successfully without errors--our TEKTRONIX 4693D Color Image
Printer software does it all the time.  When I asked TEKTRONIX how they
did it, their answer was the programmer no longer worked at TEKTRONIX, so
they didn't know. (I suspect they rewrote pr_load() from scratch, and
probably erase the mouse image prior to dumping when pulling an image off
the 3/60's). In any case, it appears that pr_load() isn't pr_loading and
therefore screendump isn't either, at least on color Sun 3/260's. Anyone
out there have any ideas? Any former TEKTRONIX programmers reading the net
today?

Howard C. Hart                  UUCP:{sun!sunncal,pyramid}!leadsv!laic!nova!hart
Lockheed Missiles and Space Co.
Orgn 59-53, Bldg 593            Ph: (408) 743-2253 or -7353
Sunnyvale, CA 94086