🚀 go-pugleaf

In article <7453@pdn.paradyne.com> alan@oz.paradyne.com (Alan Lovejoy) writes:
>In article <9734@cbmvax.commodore.com< jesup@cbmvax.cbm.commodore.com (Randell Jesup) writes:
><	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.

	Highly unlikely.  Often the bitmaps are different, and the bitmaps
are often far larger than reasonable caches (even if nothing but blitting is
going on, which is not normally the case).

	We agree that it increases the importance of the inner loop (a lot).
Scrolling and moving rectangles are also important (depending on use, of
course).

><	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.

	True.  Not all screens are "chunky", either - some are bitplanes.
However, you still need to modify all the bits of the pixels you're dealing
with, whether you write 1's or 0's.

><	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.

	It depends on usage.  And usage often depends on what's fast already.
And, as I said, unlike program execution, human perception of time is non-
linear, and also has other affects due to being able to see partially completed
renderings (often).

	The optimal bitblit for a character-only display is different than that
for one that has window borders but no patterns, which is different from one
with patterns, which is different from one that displays icons, which is diff-
erent from one that is used to display CAD images, etc, etc, etc.  Because of
this, it's important to consider all applications of your hardware.  The affect
is more pronounced than in most general instruction set design issues, but it's
there, too.  If you were here, remember the discussions between myself and
John Mashey about R2000 vs RPM-40, and the fact that we had to first define
the environment (i.e. type of programs) before doing comparisons.  R2000 is
a better match for Unix than the RPM-40 (given the same tech), RPM-40 is better
for embedded and small systems (which were a major factor in it's design).

	Designing to handle the general cases well can bring great flexibility
to the use of your hardware, even if you give up a little in some special
cases (and you may not have to).

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"