From: doiron@starpt.UUCP (Glenn Doiron)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes  (was: Chunky Chip Set...)
Date: 28 Dec 92 22:49:53 GMT
Organization: 68K Software Development
X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith

In article <1992Dec28.000531.26783@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
> In <jbickers.0m6w@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:
> >    You're kidding, right? Sure it's _possible_ to do it with planes,
> >    but don't you think it is easier (and it is definitely faster) to
> >    do it with chunky pixels?
> 
> No kidding. You are right that it is _easier_ with chunky pixels, but it
> isn't necessarily slower. At some point memory bandwidth determines
> execution speed and as long as an image needs the same memory it will
> be processed (about) equally fast. My point is that quite often you
> can live with a lower _depth_ of an image. A chunky pixel display
> will still require processing of the full depth while a planar display
> lets you strip extra bits.

Which is correct whenever you want to strip down images to a lower depth.
However, I must inform you that the discussion was about chunky-vs-planar,
not strip-down-to-lower-depth vs. leave-as-is.

> >    Well, it should be. Bypassing WritePixel() with chunky pixels will
> >    be quicker than bypassing WritePixel() with planes. There is only
> >    one address calculation, and only one write to memory.
> 
> Well, I'm not really talking about bypassing a routine and killing
> RTG compatibility.
> 
> >> Yep, drawing thin lines is a plus on chunky pixel architectures. Floodfills
> 
> >    Any kind of lines.
> 
> Nope. When you start to make lines thicker than 1 pixel you have to
> fill polygons which has some advantages on bitplanes.

Nope.  None.  Nada.  Wrong.  Incorrect.  This type of operation will almost
always be faster on chunky.  The best you can hope for w/ planar is a tie.

> >> on the other hand can be faster with bitplanes. Not sure about curve drawing
> 
> >    I don't see how flood filling can be faster with planes. The
> >    classic method is mostly ReadPixel() and WritePixel() operations,
> >    which chunky pixels excel at.
> 
> :) Hmm, the classic method is using Flood(). There's nothing that forbids
> the graphics.library to access the hardware and use every optimization.

However, a great deal of the traditional graphics functions function much
faster on chunky systems than planar systems.  ReadPixel() and WritePixel()
are two, but others not commonly used on the Amiga (due to a combo of weak
base CPU/planar architecture) are 2d-bitmap-matrix transformations, such as
scaling, rotation, warping, etc.  All these operation are *much* faster on
a chunky pixel architecture.  I can't think of a single 256-color operation
that will be faster on a planar-architecture than a chunky architecture.
Honest.

> >> but most curve drawing routines I know need several multiplications per point.
> >    So? There are incremental algorithms for drawing some sorts of
> >    curves (like circles), and having chunky pixels isn't going to
> >    make the calculation of the curve faster, but it WILL speed up the
> >    WritePixel() part of the routine significantly.
> 
> True. But the WritePixel() (noone will use WritePixel !) part is only a
> small part of the rendering operation.

Aargh.  Here's a comparison:

(256 color mode)  AGA (16-bit accesses)      Chunky (16-bit accesses)
 32-point line:   256 reads 256 writes       32 writes

 32-point line,
 2 pixels thick:  512 reads 512 writes       64 writes
 (Why are bitplanes better for this?  Seems like an additional 960 memory
  accesses to me.)

 32x32 blit:      1536 reads 512 writes      1024 reads, up to 1024 writes
         or up to 2304 reads 768 writes
 (second case if either source or dest. non-aligned)
 (including transparency/masking)

 Scaling: 32x32 image, blow up to 64x64
  convert to chunky: 8192 reads              no-op
  do mathematical xforms                     do mathematical xforms
  convert to bitplane: 32768 reads           no-op

OK, now tell me which one will be slower?  I'm not even factoring in the
ridiculous amount of bit-shifting and masking involved in all these
operations for AGA (excluding the 32x32 blit... blitter was assumed).

> -- 
> Michael van Elst
> UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
> Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
>                                 "A potential Snark may lurk in every tree."

Glenn Doiron (who thinks this chunky vs. planar stuff is hogwash anyways..
              we need both...)
--
Amiga UUCP+
Origin:  uunet.uu.net!starpt.UUCP!doiron (Organization:68K Software Development)
         BIX: gdoiron

** Not enough memory to perform requested operation.  Add 4 megs and retry.
Newsgroups: comp.sys.amiga.programmer