Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!pdn!oz!alan
From: alan@oz.nm.paradyne.com (Alan Lovejoy)
Newsgroups: comp.arch
Subject: Re: hmmm
Message-ID: <7453@pdn.paradyne.com>
Date: 22 Feb 90 18:44:26 GMT
References: <7398@pdn.paradyne.com< <9734@cbmvax.commodore.com>
Sender: usenet@pdn.paradyne.com
Reply-To: alan@oz.paradyne.com (Alan Lovejoy)
Organization: AT&T Paradyne, Largo, Florida
Lines: 59

In article <9734@cbmvax.commodore.com< jesup@cbmvax.cbm.commodore.com (Randell Jesup) writes:
<In article <7398@pdn.paradyne.com> alan@oz.paradyne.com () writes:
<>>In any case, bitblt is memory bound as it is ("bitblt plays havoc with
<>>data caches" [Pike], after all).  I doubt that a single instruction BMERGE
<>>would help the typical bitblt inner loop very much.
<>
<>But most BitBlt calls are for relativly small regions, such as when blitting
<>character glyphs.  Often, the inner-most loop never executes in such cases,
<>because each pixel row falls entirely within the same word, or only crosses
<>one word boundary.  Another important case is when drawing vertical lines.
<>Remember, 32 * 32 = 1024; it only takes 32 32-bit words to store a full line
<>of monochrome pixels on a megapixel (1024x1024) screen.
<
<	Be careful of one's assumptions.  On some systems, the relative
<frequencies of character (small) blits to animation/gfx (large) blits is
<reversed, or at least a different balance.  Also, once the character speed
<is "acceptable" (a moving target, true), speed of other operations (like
<large-area drawing, line-draw, animation, etc) can become more important to
<the market, even if character display predominates in volume.  This is of
<course because humans can see the rendering speed, and there are threshold
<levels at which perception of speed is different (especially given scan rates
<and persistance of vision).

Animation invovles repeatedly blitting the same SOURCE bitmap to the screen.
This increases the likelihood that the source pixels will be in the cache,
one would think.  And the longer each pixel-line is, the more the speed of
the innermost loop dominates overall blit speed.

<	Also watch out for assumptions about screen depth.  Even character
<blits spend more time in the inner loop on, say, a 24-bit deep screen.

Not necessarily.  Just because the destination bitmap is N bits per pixel
does NOT mean the source bitmap is N bits per pixel, ESPECIALLY in the
case of character glyphs.  Also, I have found that it is more efficient to 
blit an entire string of characters from one-bit-per-pixel character glyphs
to a one-bit-per-pixel temporary bitmap, and only then to blit the temporary
bitmap to the actual multibit-per-pixel destination than it is to do pixel-depth
changing blits a character at a time (2 to 3 times faster!).  This is due to
the special characteristics of the pixel-depth changing bitblt algorithm (or at
least, the one I desinged and use), because it has a very high setup cost but
is otherwise VERY efficient.  This algorithm translates source pixels into
any arbitray set of destination pixels as a "free" side effect of the change
in pixel depth.

<	Where special hardware is useful is for non-special cases, like
<diagonal lines - look at the difference between horizontal/vertical line
<draw to diagonal linedraw speed on machines such as the Mac and the Amiga.
<The Mac is very fast at horiz/vert line-draw, but (relatively) slow at
<diagonals (by a large factor).  The Amiga shows _much_ less degradation on
<diagonals due to the built-in blitter with line-draw.

But what is the relative frequency with which diagonal lines are drawn as
compared to non-diagonals?  RISC teaches that one should optimize for the more 
frequent cases.

____"Congress shall have the power to prohibit speech offensive to Congress"____
Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL.
Disclaimer: I do not speak for AT&T Paradyne.  They do not speak for me. 
Mottos:  << Many are cold, but few are frozen. >>     << Frigido, ergo sum. >>