Path: utzoo!attcan!uunet!cs.utexas.edu!usc!apple!ames!pasteur!ucbvax!BRL.MIL!moss
From: moss@BRL.MIL ("Gary S. Moss", VLD/VMB)
Newsgroups: comp.sys.sgi
Subject: Re:  BITBLT for 3030?
Message-ID: <8907071121.aa24621@VMB.BRL.MIL>
Date: 7 Jul 89 15:21:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 38

[Jim Disbrow writes]
< Does anyone know if bitblt is possible for the 3030?
< I need to do some block transfers as quickley as possible.

Well, I was doing postage-stamp animation a few years ago, and convinced
myself that there was no bitblt-like operation for the IRIS and resigned
myself to using rectcopy().  I did notice something that might help you
however:  If the destination rectangle of the rectcopy() had an X coordinate
which was a multiple of 16 (i.e., rectopy's 5th argument), than the copy
was *very* fast, but anything else was blindingly slow.  I don't recall if
the source rectangle's position was a factor or not (either it wasn't or
my source rectangle happened to be aligned).  What I used to do was allow
the user to position the animation-viewing window, and then would nudge its
position to be in alignment as below:

	/* Get origin of frame buffer window (source). */
	getorigin( &xwin, &ywin );

	/* Create destination window for movie, with user positioning.  */
	prefsize( framesz, framesz );
	if( (movie_gid = winopen( "movie" )) == -1 )
		{
		fb_log( "No more graphics ports available.\n" );
		return;
		}
	/* Adjust window position optimally for fast "rectcopy()". */
	getorigin( &movie_xwin, &movie_ywin );
	if( ((xwin - movie_xwin) % 16) != 0 )
		movie_xwin += (xwin - movie_xwin) % 16;
	while( movie_xwin > XMAXSCREEN - framesz )
		movie_xwin -= 16;
	winmove( movie_xwin, movie_ywin );

I called this in to the SGI Hotline and went back and forth with them for
a while to figure out if it was a bug, and I think they eventually decided
that it was just a hardware design limitation.

-moss