hsc@vuse.vanderbilt.edu (Hsuan Chang) (03/31/89)
Guy Shaw (paralogics!shaw@uunet.uu.net) writes on March 7 (in v7n194): > I know that if the screen is changed during a screendump, for example by > mouse movement or by the clock hands changing, then the rasterfile may be > corrupted and screenload will fail. I have seen warnings about this in > Sun's manuals and in articles in Sun-spots. But what I have not seen is > an explanation. >From my recollection, I can see the answer lies in that screendump generates a Sun Raster file, which happens to be using some kind of encoding (Run-length?? A few month back there were quite a few discussions about Sun Raster format, wnl might be able to point you to the relevant sunspots issues). Usually an encoding scheme is global in that all the pixels are to be accessed during the encoding process. Hence, the system has to retain the image for at least as long as the pixels are encoded. Hsuan Chang Image Processing Lab Computer Science Dept Vanderbilt University, Nashville, Tn 37235 (615) 322-0962 343-6259 hsc@vuse.vanderbilt.edu [[ Discussion of the rasterfile format can be found in the following volume 7 issues: 69, 82, 85, 88, 91, 98, 100, 106, 144. --wnl ]]
beau@ames.arc.nasa.gov (Beau James) (03/31/89)
The image corruption occurs because some of the framebuffers have hardware
state, and that state is not preserved/restored across context switches.
The most notable example of that state is the RasterOp accelerators on
many of the color framebuffers.
There is no hardware-level interlock. And since most applications,
including SunView and screen{dump,load}, access the framebuffer by
mmap()ing it and writing directly, the kernel doesn't have a chance to
single-thread the operations in the device driver. SunView handles this
problem by providing locking aound screen update operations; the lock is
at the pixwin level.
The worst result is a corrupted image in the dump. The image will still
be screenload'able, it will just look bogus. The problem with
non-loadable screen images was separate, I believe: a bug in some 3.x
versions of the byte-length-[en,de]coding software, fixed in 4.0.
Screendump was designed to be able to take snapshots of the contents of
the framebuffer, regardless of what had put those bits there. So it
doesn't assume that any particular window environment is running (or for
that matter, any window system at all). Screendump could be made more
robust, by having it check whether it is running under a SunView
environment and, if so, using pw_lock() to ensure exclusive access to the
framebuffer during the copy-out operation. But there is no way to ensure
"atomic" screendumps in the general case.
Beau James beau@ultra.com
Ultra Network Technologies sun!ames!ultra!beauhart@decwrl.dec.com (Howard C. Hart) (03/31/89)
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 94086david@sun.com (04/22/89)
ultra!beau@ames.arc.nasa.gov (Beau James) writes: > ...The problem with >non-loadable screen images was separate, I believe: a bug in some 3.x >versions of the byte-length-[en,de]coding software, fixed in 4.0. I've told you before, Beau... it was a bug in the original "byte-length-[en,de]coding software", fixed in 3.4. No wonder you had to resign :-)