disbrow@skipper.dfrf.nasa.gov (Jim Disbrow) (07/06/89)
Does anyone know if bitblt is possible for the 3030? I need to do some block transfers as quickley as possible. On other machines I'm familiar with, the command is always some form of bitblt, But I can't seem to find a similar command in the IRIS documentation. If someone knows how to do this on the 3030, I'd really appreciate a response. Thanx in advance Jim
moss@BRL.MIL ("Gary S. Moss", VLD/VMB) (07/07/89)
[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.
-mossmsg@fiji.sgi.com (Mark Grossman) (07/14/89)
In article <8907071121.aa24621@VMB.BRL.MIL>, moss@BRL.MIL ("Gary S. Moss", VLD/VMB) writes: > 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 Actually, this speedup can be achieved by ensuring that the DIFFERENCE between the source and destination rectangle positions is a multiple of 16.
msg@fiji.sgi.COM (Mark Grossman) (07/14/89)
Return-path: info-iris-request@vmb.brl.mil Received: from VMB.BRL.MIL by CCVAX.IASTATE.EDU; Fri, 14 Jul 89 03:53 CST Received: by VMB.BRL.MIL id ad02927; 14 Jul 89 0:25 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ab00083; 13 Jul 89 17:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab25311; 13 Jul 89 16:22 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28051; 13 Jul 89 15:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA05470; Thu, 13 Jul 89 11:17:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Jul 89 17:13:57 GMT From: Mark Grossman <sgi!msg%fiji.sgi.com@ucbvax.berkeley.edu> Subject: Re: BITBLT for 3030? Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL References: <8907071121.aa24621@VMB.BRL.MIL> Organization: Silicon Graphics, Inc., Mountain View, CA Message-Id: <37889@sgi.SGI.COM> In article <8907071121.aa24621@VMB.BRL.MIL>, moss@BRL.MIL ("Gary S. Moss", VLD/V MB) writes: > 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 Actually, this speedup can be achieved by ensuring that the DIFFERENCE between the source and destination rectangle positions is a multiple of 16.