[comp.sys.mac] QuickerDraw

alibaba@ucscb.UCSC.EDU (73539000) (02/03/88)

---
What do people know about QuickerDraw? What does it improve/change?
How does it work? Why? What does Apple think about it? Where can I get
it?

If you know any of the above, then you may have already won...


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~  Alexander M. Rosenberg  ~ INTERNET: alibaba@ucscb.ucsc.edu   ~ Yoyodyne    ~
~  Crown College, UCSC     ~ UUCP:...!ucbvax!ucscc!ucscb!alibaba~ Propulsion  ~
~  Santa Cruz, CA 95064    ~ BITNET:alibaba%ucscb@ucscc.BITNET  ~ Systems, Inc~
~			   ~ Disclaimer: Nobody is my employer  ~ :-)         ~
~			   ~ so nobody cares what I say.	~	      ~

mkb@ROVER.RI.CMU.EDU (Mike Blackwell) (02/04/88)

The way I understand it, Hertzfeld made the remarkable discovery that when
you're in 8-bit mode, you never have to check if you need to do bit shifts,
since you're always byte aligned. Saves a couple of instructions per pixel,
which could be substantial. Why the color QuickDraw implementers didn't
figure this out, though, is beyond me - operating in 8-bit mode is common,
and should have been special cased in the first place.

		Mike Blackwell  ...  mkb@rover.ri.cmu.edu

kwallich@hpsmtc1.HP.COM (Ken Wallich) (02/05/88)

>What do people know about QuickerDraw? What does it improve/change?
>How does it work? Why? What does Apple think about it? Where can I get
>it?
----------
It is an init which patches some of the low level quickdraw routines
with code that is supposidly faster than "original flavor" quickdraw.
Andy Hertzfield claims up to 350% increase in performance "especially
in drawing and selecting text".  Well, since drawing and selecting
text is near instantaneous (I am running it on a macII) I have noticed 
no increase in speed.  I noticed around a 25% increase with some 
big quickdraw things, but were talking 15 instead of 19 seconds 
to draw a complicated picture on a 13" mac screen.  Not exactly 
staggering.  Perhaps with a 19" monitor...

I found version .9 floating around on some BBS around here, perphaps
version 1.0 will be faster.

Apparently Andy talked to Scully about it at MacWorld, and Scully told
Andy that it would be best marketed by someone else (Andy still doesn't
realize that Apple doesn't like any of Steve's friends...)  The Raster-
Ops folks said that if Apple doesn't market it, they will.  Andy thinks
$75 bucks is a good price for it, however since it is <10K, is not
copy protectable (it is an init), and doesn't blow you away, I think
he is out of his mind, and at $75 it will be illegally copied faster
than you can say "please insert the disk untitled".

Version .9 also is not 100% quickdraw compatable, and I have noticed
several programs which don't draw correctly with it in use (everything
works ok, until you go into 256 color mode).  Perhaps it speeds up an
"ordinary mac", but mine is out on loan, so I haven't been able to test
it there yet, and from looking at the startup icon (a rainbow effect),
it may only be for a MacII (don't quote me on that!)

--------------------
Ken Wallich			*My views are mine, and mine alone*
Consultant			"Slimey? Mud Hole? my HOME this is!"
DCI 				kwallich@hpsmtc1.HP.COM
@Hewlett Packard		...hplabs!hpsmtc1!kwallich

"If we weren't all crazy, we'd all go INSANE"

olson@endor.harvard.edu (Eric K. Olson) (02/05/88)

In a recent article Mike Blackwell writes:
>The way I understand it, Hertzfeld made the remarkable discovery that when
>you're in 8-bit mode, you never have to check if you need to do bit shifts,

In early Mac II documentation, there are references to 16 and 32 bit modes.
It's a pity these were eliminated, since the 24-bit cards now becoming
available have a painful programming interface...

Then again, a full 16-bit color lookup table would be about 524K.  A 32-bit
one would be about 34 Gigabytes-- perhaps these resolutions were never
intended to be used with color-lookup tables.

The same document referred to 1-1-1, 2-2-2, 4-4-4, and 8-8-8 chunky-planar
pixel organizations (the 8-8-8 would have been perfect for the OpCode or
SuperMac 24-bit cards).

-Eric


Eric K. Olson     olson@endor.harvard.edu     harvard!endor!olson     D0760
   (Name)                (ArpaNet)                 (UseNet)        (AppleLink)

lsr@apple.UUCP (Larry Rosenstein) (02/06/88)

In article <11540125@hpsmtc1.HP.COM> kwallich@hpsmtc1.HP.COM (Ken Wallich) writes:
>
>Version .9 also is not 100% quickdraw compatable, and I have noticed
>several programs which don't draw correctly with it in use (everything
>works ok, until you go into 256 color mode).  Perhaps it speeds up an

My understanding is that it only speeds up operations in 256 color mode.  It
doesn't do anything on a non-Mac II (a Mac I ?) or on a Mac II with less
than 256 colors.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc}!apple!lsr
CSNET: lsr@Apple.com

dhac@ur-tut.UUCP (Darren Jay Hacker) (02/07/88)

[munch, munch, munch...]

>>What do people know about QuickerDraw? What does it improve/change?
>>How does it work? Why? What does Apple think about it? Where can I get
>>it?
>----------
>It is an init which patches some of the low level quickdraw routines
>with code that is supposidly faster than "original flavor" quickdraw.
>Andy Hertzfield claims up to 350% increase in performance "especially
...
>I found version .9 floating around on some BBS around here, perphaps
	 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>version 1.0 will be faster.

Perhaps you could upload it to comp.binaries.mac, oe e-mail me/us a copy!
I'm sure that if version .9 is impressive to some of us, we may actually go
out and purchase a copy when it becomes "released"!  I do a lot of graphics
stuff on my SE, and anything that speeds up screen output is a boon for me!
I only have net and FTP access so I cannot peruse any BBS's at this time...
So, if uploading/mailing does not violate any (c)-laws, then please share it!

Darren Jay "DJ" Hacker

=============================================================================
Darren Jay Hacker	  Internet: dhac@tut.cc.rochester.edu
"The fault, dear Brutus,      UUCP: dhac@ur-tut.UUCP		    \ / ,|.
 is not in our stars,	       (or) ...{ames,cmcl2,decvax,rutgers}   X ( | )
 but in our software		       !rochester!ur-tut!dhac	    / \ `|'

wetter@tybalt.caltech.edu (Pierce T. Wetter) (02/11/88)

In article <801@PT.CS.CMU.EDU> mkb@rover.ri.cmu.edu (Mike Blackwell) writes:
>The way I understand it, Hertzfeld made the remarkable discovery that when
>you're in 8-bit mode, you never have to check if you need to do bit shifts,
>since you're always byte aligned. Saves a couple of instructions per pixel,
>which could be substantial. Why the color QuickDraw implementers didn't
>figure this out, though, is beyond me - operating in 8-bit mode is common,
>and should have been special cased in the first place.
>

  More likely is that Hertzfeld realized that its silly to pack the 1,2,4, and
8-bit modes together. A faster way is to make each pixel a byte but only 1,2,4,
or 8 are significant. This way rather then toggling bits you can simply blow
away the byte which is much faster.
 The 24-bit boards have this problem as the present quickdraw is unable to 
simply set all 24bits by doing a long word write, rather is sets each in turn.
 Arrgh!

 rampant sillyness
Pierce Wetter
wetter@tybalt.caltech.edu

"When you are in it up to your ears, keep your mouth shut."

--------------------------------------------

wetter@tybalt.caltech.edu

--------------------------------------------