Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: mcvax!cel!ajy@uunet.uu.net (andrew yeomans)
Newsgroups: comp.sys.sun
Subject: Re: Rasterfile Format questions
Message-ID: <8901111837.AA03581@sun302.cel.uucp>
Date: 16 Jan 89 08:22:03 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 71
Approved: Sun-Spots@rice.edu
Original-Date: Wed, 11 Jan 89 18:37:36 GMT
X-Sun-Spots-Digest: Volume 7, Issue 106, message 2 of 5

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@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@cel.uucp
Hertfordshire		      mcvax!cel!ajy@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);
}