NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/amiga/programm/17940

Internet Message Format | 1992-12-29 | 6.3 KB

Path: sparky!uunet!olivea!bunker!nuconvex!starpt!doiron
From: [e-mail] (Glenn Doiron)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Message-ID: <[e-mail]>
Date: 30 Dec 92 03:16:54 GMT
References: <[e-mail]> <[e-mail]>         <[e-mail]>
Organization: 68K Software Development
Lines: 121
X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith

In article <[e-mail]> [e-mail] (Michael van Elst) writes:
> In <[e-mail]> [e-mail] (Glenn Doiron) 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.)
>
> It would be still 256 reads 256 writes unless the line spans over a word
> boundary. More, shallow lines will need less reads and writes.

Whoa, where I come from, you draw a double-thick line by (1) drawing 2
lines next to each other or (2) plotting a 4x4 brush along the course of
the line.  (1) being faster than (2), since you are plotting 1/2 the
points.  When you say "plot this point and the one next to it if it's in
the same word boundary", you are talking special hardware.  BTW you are
still confusing the issue;  you are comparing a 32-bit cpu access planar system
to an 8-bit cpu access chunky system.  I will tell you right now that you will
*NOT* find an 8-bit CPU access chunky pixel system on an Amiga; they will all
be 16-bit or 32-bit.  Chunky can pull 4 pixels in one fell swoop on a 32-bit
system.

> However, your line drawing routine will need cycles itself. So unless
> your rendering is done in hardware the difference gets smaller.

TMS340x0's have Bresenham's line-drawing algorithm embedded in hardware.
They also support chunky-pixel displays.  They don't support planar
displays.  I wonder why.  Oops, I strayed from the topic too, sorry...

> > 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)
>
> 32x32 blit is 512 reads/writes. more for non-aligned objects. chunky
> needs 512 reads/writes and a little more for non-aligned objects.
(I was using the Amiga's blitter as a reference here)
> (Both do word accesses).

Here you go again.  First you're talking about 16-bit accesses, now 32-bit
accesses.  Please compare planar 32-bit vs. chunky 32-bit, not planar
32-bit vs. chunky 8-bit, as you seem oblivious to the differences.  In any
case, the planar system will almost always lose for two reasons:

  1  Chunky doesn't need to do a write if this is a transparent pixel.
  2  Chunky doesn't lose time if the data is not perfectly/wholly aligned.

Here's the point:  <<EACH SYSTEM HAS TO MOVE THE SAME AMOUNT OF DATA>>,
but <<PLANAR MUST AFFECT ANY ADJACENT PIXELS IN THE BOUNDARY WHILE CHUNKY
DOES NOT>>.  (once again ignoring the shifting/masking aspects which you
seem to patently ignore as if they were of no consequence at all)

>
> > 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
>
> That's easy. 'blow up' is a table lookup which can be done on each bitplane
> independently. No need to convert from and to chunky. If you use a selected
> colormap then you get filtering/dithering of the image for free.
> BTW, that's the same speed for chunky/bitplanes.

So how is doing 8x the number of mathematical transformations possibly
going to be faster, not to mention the masking/bit shifting?  And 'table
look-up' isn't anywheres close to general purpose.  Once again, you're
talking about a special-case optimisation, one that can also be done with
chunky pixels just as well.

> >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).
>
> Chunky wins slightly in most operations IF you use a 256 color image.
> It looses with a depth != 8.

Planar loses almost *always* in these operations, even if you have
dedicated hardware like the Amiga's blitter.

> BTW, 32x32 blit is tiny, what about 50x50
> or 156x200 ?

Planars's losses go up directly as your blit gets larger.  The overhead for
the mathematical xforms is the same, but with what you're saying, planar
will take N times longer, where N is the number of bitplanes.

> And since we were talking about 'image processing'. Most tools
> have some sort of GUI which eats some of the 256 colors. The easiest
> way is to go down to 128 colors. Bitplanes will then be faster for 12.5%.

Bitplanes will be faster for 12.5% whenever you have data that is perfectly
aligned, perfectly sized, and special hardware to do those shifting and
masking operations which you seemingly dismiss as taking no cpu-time
whatsoever {evil grin}.  Unfortunately, this is seldom the case, and even
in 7-bit color chunky will win in most of the operations being discussed.
Now, if you are talking about copying entire screens of data, like ANIM,
yes, planar can take that 12.5% speedup.  But most graphic operations will
do much better on planar than chunky.

Tell you what.  Code a routine that
will plot a line from (X1,Y1) to (X2,Y2) in color C on an 8-bitplane 32-bit
access system.  Now do the same thing for an 8-bit chunky 32-bit access
system.  Look at the code.  Tell me which one is doing (a *hell of a lot*)
more calculations.   Which one accessing video memory (a *hell of a lot*)
more often.  Now, tell me which one is going to run faster on *any*
machine?

 INCLUDE "misc/end_of_thread.i"

> Regards,
> --
> Michael van Elst
> UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
> Internet: [e-mail]
>                                 "A potential Snark may lurk in every tree."

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