From: mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sun, 3 Jan 1993 03:51:12 GMT

In <doiron.0kil@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
>... and you still haven't convinced me that chunky isn't faster.  As was
>said before, the best you can hope for is break-even, and far more often
>chunky will be faster - the bigger the blit, the smaller the difference.

The difference vanishes if the bitplanes are well aligned. Otherwise, except
for tiny bitmaps such as single pixels, the difference is neglible.

Remember, it is a tiny difference since only borders are affected in most
operations. Bitplanes will win if you can strip whole bits from all pixels
(i.e. cut down on pixel depth).

>As I said, you lose all the performance gains VRAMS were supposed to give
>you in the first place, since you can't use the serial registers for video
>fetch in planar setups.

I wouldn't be so sure :)

>Chunky has this property too, although only to a power of two.  This
>however, is not nearly good enough justification for all the penalties you
>get in planar doing everyday operations.  Why use a lesser number of colors
>when you can use more for the same, if not better, performance?
> 

Using more colors (more bits per pixel) will always degrade performance.
But in bitplanes you could f.e. use 1024 colors instead of either 256 or
65536.

>No.  It is not.  You are doing N time the amount of work in planar, where N
>is the number of planes.

Sorry, not at all.

>Best of luck to you.  You are talking really expensive hardware now.  Not
>something you'd tack onto an Amiga, or anything, since chunky is here now,
>costs less, and doesn't have any of these deficiencies to which your
>special-purpose hardware would address.

>Nope.  "Special case".  You can't use the same algorithm to stretch that
>32x32 image into, say, 64x57 or shrink it to 17x13.  You might be able to
>do 64x32 or 32x64.  But that's still a special case optimization.

Well, it is a bitmap scaling by an integer factor. Anything else needs
filter operations.

>Shifting is too slow on almost any general purpose processor, not just the
>68000.  Irregardless, you need to do a lot of shifting/masking, which isn't
>going to be free on --any-- processor, although custom chips can go a long
>way towards hiding this via pipelining/superpipelining.

It isn't a long way. There's really no problem to hide shifts behind
memory accesses if you stay with reasonable word lengths. Maybe a 128bit
barrel shifter would be too slow.

>Can you use that table to do another transformation, as noted above?  No.
>It's a special case optimization.

Can you use your chunky bitmap scaling routine for another transformation ? 

>few break-even cases.  Sometimes it will even be faster on chunky *even
>with a reduced scale for planar*, since chunky doesn't need 'bit
>thrashing'.

"Doesn't need" is wrong unless you operate on a memory that is one
pixel 'wide'. You hardly do.

>In all cases, you've admitted that chunky is faster than planar (w/
>exception of you special case optimization where it breaks even).  I rest
>my case.

...and silently forget depth scaling.

>Would help if you didn't delete too much from the above references.
>Plotting an alternating color horizontal line will still be (w/ 8-bit
>color) 8x faster on chunky than planar.  Plotting every other pixel a
>different color isn't going to make planar faster.

Plotting an alternate color horizontal line is same speed. You simply
determine the pattern you have to mask through.

>:)  Look, if you want a 128-color display, I won't forbid you from using a
>planar architecture.  However, drawing a line will be far faster on a
>256-color chunky than a 128-color planar display.  If you need a
>4,16,256,65536, or true-color display, however, your losses using planar
>will be even more dramatic as the number of colors goes up, since you are
>wasting 2x, 4x, 8x, 16x, or 32x the amount of time accessing irrelevant
>data (still not counting shifting/masking).

No. With single pixel lines the losses are determined by the word length,
not the number of planes. Wether you write 8bits per pixel or 24bit per
pixel. The _ratio_ is still the same.

Regards,
-- 
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."