[comp.lang.c] Speeding up code

mckenzie@june.cs.washington.edu (Neil McKenzie) (10/04/88)

In article <225800077@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:

>3.     Don't use a complicated canned system to push square pegs
>in round holes. This is where I have found my factors of 300. Graphics
>systems like GKS and Phigs are the classic case, as are the graphics
>routines in Microsoft Windows (and, I'll bet a cup of coffee, OS/2),
>but not, for some odd reason , the Mac. Those things go through so
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
>many layers of code from your call to the screen that they are
>guaranteed to be slow.
>
>Doug McDonald

This is precisely the reason that the Mac wins as a whizzy-interface
micro.  If the Mac did its screen updates slowly, no one would have
ever bought it.  This is why packages like MS Windows are Quixotic
attempts to make the IBM PC a graphically appealling micro.  But since
the PC was never designed from the ground up to support this, Windows
is a turtle.  Some of the other micros (Amiga, Atari ST) seem to do a
fair job of pushing pixels given their built-in functions, like the Mac.
Give the implementers some credit here!

The moral is:
    People prefer to use standards only if they are well implemented.

Neil McKenzie (mckenzie@june.cs.washington.edu)

"La Bomba Chelter -- where bad food and bad people go together"
-- Firesign Theater