Rasterfile Format questions

[andrew yeomans]

Further to my message on raster files being corrupted by pr_dump when
using RT_BYTE_ENCODED:

I believe the bugs are fixed in the latest Sun releases.  I had problems
with a program built with an early version of pr_dump, which sometimes
refuses to save or load small pixrects, especially when the data would
contain values of 0x80.

'what' reports that the buggy version of the module containing pr_dump is
'pr_io.c 1.1 85/12/19'.  On SunOS 3.5, (yes, I'm still looking forward to
the joys of 4.x!)  the version is 'pr_io.c 1.5 87/08/14', which does not
have the problem.

Conclusion: Software built with an early version of the pixrect library
may fail to save certain pixrects properly. Solution: rebuild it!

	Andrew Yeomans
__________

Patrick J. McEvoy (Sun Entry Systems ISV Liason) <swagman at sun.com> adds
the following:

>	The sun routine pr_dump does not always encode RT_BYTE_ENCODED
>	rasterfiles correctly, if copy_flag = 0 (compress in place).

Not quite.  copy_flag = 0 means don't bother making a copy of the *source*
pixrect before doing all the work.  Nothing is done in place.  (One might
want to make a quick copy of the source pixrect if the data is subject to
modification by another process, e.g. the framebuffer.)

>  My copy of "Pixrect Reference Manual" (admittedly old, dated 17 Feb 1986)
>  states that:
>    "There are two situations where the copy_flag value should be non_zero:
>    
>    -	If the output type is RT_BYTE_ENCODED - This is because the encoding
>    	algorithm does the encoding in place and will destroy the image data
>    	of input_pr if it fails while working on input_pr directly.
>    -	if input_pr is a pixrect in a frame buffer ...."

The 4.0 source code currently really does write directly to a FILE *, when
you specify RT_BYTE_ENCODED.  Nothing gets kept around in memory.

More likely, you can run into trouble when pr_dump'ing a CG2, CG3, or CG5
if the screen gets updated during the dump (likely if you are running a
clocktool).  The CG? has hardware registers that put it into one of
several address modes: 8-bit pixels, 8 1-bit pixel planes, rasterop mode.
Normally the window system cordinates those registers, but pixrects alone
(e.g.  pr_dump) does not.  So if those registers get hit during your dump
the rest of your image is foobar -- even if you specify RT_STANDARD.  Try
setting the copy_flag.

Feel free to post anything I said to sunspots.


Andrew Yeomans		PSTN: 0442 230000 ext 3371
Crosfield Electronics Ltd	INTL: +44 442 230000
Three Cherry Trees Lane	Fax:  0442 232301
Hemel Hempstead		UUCP: ajy at cel.uucp
Hertfordshire		      mcvax!cel!ajy at uunet.uu.net
HP2 7RH
England

>From a program you can call wmgr_refreshwindow (Sunview System
Programmer's Guide Chapter 13 on Window Management). Example: 

main(){
	int rootfd;
	rootfd = open("/dev/win0",0);	/* or getenv("WINDOW_PARENT") */
	if(rootfd>=0)wmgr_refreshwindow(rootfd);
	exit(rootfd<0);
}